Decide how much work the AI may carry
Copilot and agent say almost nothing about what the software may actually do. One copilot may only draft. Another may update records. One agent may plan and wait for approval. Another may execute across several tools. Tcules defines what the AI may know, propose, prepare and do, then designs planning, evidence, permission, progress, interruption and recovery around that boundary.
Decide how much the AI may do
Add an editorially reviewed accessibility summary before publishing.
| Authority level | Product behaviour | Essential control |
|---|---|---|
Inform | retrieve or summarise without changing product state | source coverage and correction |
Suggest | propose an answer, option or next action | alternatives, edit and rejection |
Prepare | assemble a plan, draft or change set | affected objects and review before commitment |
Execute one bounded action | call one permitted tool under explicit conditions | permission, confirmation where required and result state |
Act across steps | plan and use several tools toward an objective | checkpoints, stop, partial-state recovery and history |
The agentic UX definition explains why a multi-step agent needs plan visibility, permission, stop conditions and recovery.
More permission is not automatically a better product. The level should follow what is at stake, whether the action can be undone, how good the evidence is, and whether the user can step in.
The action contract makes delegation reviewable
For each action, record the trigger, authority, context, checkpoint, evidence of effect and failure route. The run must distinguish ready, working, approval-required, partially complete, handback and complete states. If an approved external action returns an uncertain result, the product should reconcile the authoritative state before retrying or claiming success.
The article on generative AI product patterns helps teams compare delegated action with narrower retrieval, recommendation and orchestration patterns before committing to an agent.
Use a delegated task and its failure path to expose who approves the action and what must happen when it cannot complete safely.
What exactly does a person approve?
Approval attaches to a bounded action: the affected objects, exact payload or change, current state, permitted tool, consequence and recovery path. The product records who approved it and what happened next. Prompt instructions may guide behaviour, but consequential permissions must be enforced at the tool, identity and policy boundary.
Partial success is a product state
When an agent works across tools, one action can succeed while the next fails. The product must distinguish:
- not started, queued, active and awaiting input;
- completed, failed, skipped and cancelled steps;
- external action completed but local state not reconciled;
- retry that is safe from retry that could duplicate an action;
- a plan changed by the person after execution began;
- work that can be reversed from work that requires manual recovery.
A reassuring progress animation cannot substitute for these states.
Recent product evidence
ConnectX bounded model freedom through eight situations connecting intent, tools, data, modules and action. BuildTwin shows human correction and escalation remaining visible when an AI result affects expert review.
The cases support product architecture and control decisions. They do not establish a production autonomous agent or operational outcomes.
When not to use an agent
Use a direct interaction, deterministic workflow or normal automation when the task is stable, short, easier to inspect manually or too consequential for delegated execution. An agent should reduce meaningful work, not make a simple state harder to understand or recover.
Tcules can continue from authority and interaction design into coded demonstrations, model and tool integration, evaluation and software delivery under the agreed environment and review boundary.
Design delegation with clear boundaries
Bring the objective and proposed authority so the product can define planning, permission, state and recovery before implementation.