An AI-assisted plugin can draft a refund recommendation in an afternoon.
It should not redefine who can run the action, when approval is needed, or what proof survives.
That is the distinction this article draws.
AI has made workflow software faster to build. That is useful for plugins, integrations, summaries, and operator assistance.
It is dangerous when the same fast-moving layer can redefine the control boundary.
This Is For
- teams building AI-assisted approval or action workflows
- operators and architects deciding what belongs in a plugin versus the core
- leaders who need speed without making approval, auth, and audit a moving target
The Risk Is Not "Using AI"
The problem is not that AI exists in the workflow.
The problem is when the wrong part becomes soft, unstable, or poorly reviewed.
AI can draft a plugin that summarises a case. It can prepare a suggested refund. It can propose the next offer. That is useful.
The same fast-moving layer should not decide these things:
- who can act
- which actions need approval
- whether the requester and approver must be different people (maker-checker, or two-person review)
- what gets logged
- which denied attempts survive
- what evidence remains
These are not convenience features. They are the rules that keep the workflow safe, explainable, and defensible.
The Control Boundary Must Stay Stable
Before the details, the rule is short:
- plugins can suggest
- plugins can collect input
- plugins can execute an already-allowed step
- plugins should not redefine who is authorised
Plugins should not redefine when approval is required. Plugins should not redefine what counts as the audit trail.
If you are evaluating a live workflow, start with approval workflows in Latch or talk through the workflow directly.
The Core Is the Part That Must Stay Stable
This is the layer that answers the questions a team faces after something sensitive happens.
| Question | What needs to be tracked |
|---|---|
| Who requested the action? |
|
| Who had the right to run it? |
|
| Did it require another approver? |
|
| Was anyone blocked from doing it? |
|
| What exactly happened? |
|
| What proof still exists? |
|
If that layer changes whenever a plugin is added, the organisation does not have a control model. It has a moving target.
The Stable Core Owns Authorisation, Approval and Audit
The stable core stays consistent while workflows, prompts, and plugins change around it.
In plain terms, the core handles identity and permissions. It decides when approval is required. It enforces rules and blocks forbidden actions. It keeps a permanent record of what happened.
The core says:
- "You can request this, but someone else must approve it."
- "Small amounts are fast, but large amounts need review."
- "You cannot skip the required evidence."
- "This action must be permanently logged."
These rules must hold. They should not break because a prompt changed or a plugin was built in a hurry.
This is not the place for guesswork or code written on the fly.
Plugins and Suggestions Can Move Faster at the Edge
The edge is different. Fast iteration is useful here:
- plugins for refund, offer, or CRM systems
- AI-generated summaries or suggestions
- case-specific input collection
- recommendation logic for likely next actions
- tenant-specific integrations
These pieces should evolve quickly. They sit close to the changing details of the business. They benefit from experimentation. They improve as the team learns.
But they operate inside a clear contract.
The plugin can suggest. It can collect input. It can execute an approved step. It must not redefine who is authorised or when approval is required. It must not redefine what counts as the audit trail.
This Separation Matters More With AI
Before AI-assisted development, teams still made risky workflow changes. They moved more slowly.
Now the speed of change is higher. That speed also raises the cost of weak boundaries.
A team can produce a useful plugin in a day. It can also produce a subtle approval or logging flaw in a day.
That is why architecture matters.
If the core remains stable, well-reviewed, and heavily tested, teams can use AI to accelerate the edge:
- new plugin ideas
- new customer workflows
- new downstream integrations
- better suggestions for operators
If the core also changes casually, the system becomes harder to trust.
Tested Control Logic Is What Makes Safe Speed Possible
A stable core is not a brake. It makes safe speed possible.
When approval, authorisation, and audit behaviour stay stable, the team can move faster elsewhere without weakening the workflow each time a plugin appears.
That is the architectural win. The edge becomes more useful because the control model under it does not keep changing.
This is the point teams miss.
Tested control logic does not slow AI adoption. It makes faster delivery possible without losing control.
When approval, auth, and audit are deeply tested, the organisation gains freedom elsewhere.
Teams can move faster on the edge because they are not renegotiating the safety model with every release.
That leads to a healthier operating pattern:
This is how you get speed and accountability instead of trading one for the other.
A Simple Rule: Control Questions Belong in the Core
If a new capability answers how work should be done for a customer, queue, or integration, it may belong in a plugin.
If it answers any control question, it belongs in the core:
- "Who may act?"
- "Who must approve?"
- "What gets blocked?"
- "What evidence survives?"
That rule keeps the product honest.
It also keeps AI in the right role. ChatGPT or Gemini can help teams generate useful workflow behaviour. They should not casually redefine the control boundary that makes sensitive work safe.
Latch Fits by Keeping the Control Layer in the Core
Latch keeps the control layer and the extension layer distinct.
The platform keeps approved roles, permission policy, denial visibility, execution history, and case-linked audit trails stable at the centre. Teams add plugins around that core for refunds, offers, reprocessing, or other downstream work.
That gives operators flexibility without turning approval and audit behaviour into a collection of one-off exceptions.