Services

AI Copilots and Agents

Define what an AI copilot may know, propose, prepare and do, then design planning, permission, progress, interruption and recovery around that boundary.

  • AI product UX
  • Copilots
  • Agent design
Email Tcules (opens in a new tab)

Decide how much work the AI may carry

Copilot and agent are not reliable descriptions of product authority. 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.

Choose the authority level deliberately

Each authority level changes what the product must make visible and controllable.

AI authority levels and controls
Authority levelProduct behaviourEssential 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 action contract makes delegation inspectable

Plan before authority

The user objective creates a proposed plan rather than immediate authority. Planning and execution remain distinct states even when the product allows both in one interaction.

  • User objective

    The product captures the intended outcome before proposing how work should proceed.

  • Proposed plan

    The proposed plan describes the steps, tools and affected objects before consequential commitment.

  • Evidence or preview

    Evidence or preview supports a checkpoint so a person can review the work before execution changes product state.

Execution with recovery

Each step names its tool, permission, affected object, status and evidence. A person can stop or intervene, and failures have explicit recovery with history retained.

  • Tool and permission

    Each step identifies the tool being used, the permission required and the object that may be affected.

  • Execution result

    The result updates the product state rather than disappearing into a reassuring progress indicator.

  • Exception and history

    An exception can stop, narrow, retry, reverse or route work to a person. History retains the plan, actions and interventions required for later inspection.

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.

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.

Email Tcules