The strong rivalProgressive autonomy in one product

Start with an assistant, add tools and memory, then let customers enable copilot or agent modes as trust grows. This preserves one experience, reduces migration cost and gives users choice. It can be an effective product architecture when each mode has a clear boundary and separate evidence.

The model fails when the modes are merely toggles. Users may not know which state persists, whether a suggestion can execute or how authority changed after an update. A confirmation dialog can remain visually constant while the number of actions behind it grows. Commercial terms written for drafting may not cover delegated purchasing, customer communication or remediation. Support and incident processes can lag behind the product's effective authority.

The grammar approach has its own failure mode. Teams can over-specify every interaction, write clauses that are not enforced or route stable rules through a probabilistic planner. Customers cannot use a contract they cannot understand in the moment. The purpose is a small executable grammar that connects the product promise to identity, tools, limits, evidence and recovery.

Product Contract GrammarEleven dimensions, one visible promise

The dimensions are coupled. Long-lived memory changes what an event trigger can infer. Sub-agent access changes tool depth and evidence. Standing authority changes the consequence of a supplier update. A commercial promise to complete an outcome carries different support and remedy obligations from a promise to draft a proposal.

The active contract should be legible at the moment of use. Customers need to see what initiated the work, which objective is active, what state persists, which systems can change and where an approval applies. Documentation remains necessary, but it cannot substitute for enforced limits and in-product evidence.

Compile the grammarFour operating patterns

The writing assistant is the clean assistant pattern: it drafts, retains no long-term state and cannot publish. The developer copilot keeps repository context and proposes patches while the developer selects the sequence, runs tests and commits. The procurement agent may gather quotes and negotiate within named vendors, spend and term limits, but signing outside the mandate remains segregated. A reconciliation rule with stable inputs and outcomes belongs in deterministic automation.

Patterns can coexist in one product, but each transition is explicit. A copilot may use deterministic checks before proposing a patch. A bounded agent may call an assistant to draft a message without extending the assistant's authority. The product should disclose which pattern controls each step and should prevent a lower-authority component from acquiring the caller's full permissions by accident.

Choose the pattern by outcome and control, not user enthusiasm. A customer can prefer automation that reduces clicks while lacking the information needed to evaluate an action. Another may prefer an assistant even when a bounded agent would reduce coordination work. Product discovery should test both value and the customer's capacity to perform the retained role.

Tool access and action authorityDo not hide execution behind conversation

A product that can change external state is not merely chat. The interface should distinguish read, draft, simulate, execute and delegate. A draft saved to an internal workspace differs from a message sent to a customer. A payment proposal differs from beneficiary creation and release. The active tool, target, identity and effect should be visible before the action crosses the customer's boundary.

Technical authorisation answers whether a subject may access a resource. Zero Trust and OAuth security practices strengthen identity, tokens, clients and resource decisions. They do not establish business delegation. The product still needs a mandate that names the objective, action class, population, spend, duration and exclusions. A valid credential can be used outside the commercial promise or the user's understood authority.

Per-action confirmation can be appropriate when actions are few, consequential and information-rich. It becomes theatre when users approve dozens of similar steps, cannot inspect the plan or have already invested enough attention to accept automatically. The contract should bundle actions into meaningful checkpoints, show material differences and allow the user to narrow or stop the remaining plan.

Standing mandates deserve an expiry and renewal evidence. They should be narrower than the technical capability and should not expand automatically when a tool or sub-agent is added. A new beneficiary, higher-value payment, unfamiliar jurisdiction or non-standard term can route to segregated authority. The agent can continue gathering evidence while the protected action waits.

Sub-agent invocation is delegation again. The caller should pass the minimum objective, context and permission needed, preserve identity and trace, enforce tool-depth and cumulative limits across the whole chain, and prevent the callee from converting a proposal into execution. If the original product contract does not cover the additional agent's authority, the expansion should fail closed.

Cumulative authorityBound what repeated action can become

Per-call controls miss accumulation. An agent can make many small purchases, send many acceptable messages or retry a tool until the combined effect exceeds the customer's intent. Limits should apply to the objective across time, spend, volume, population, tool depth and credible loss. The system should calculate the remaining envelope before each action and stop when it cannot prove the action fits.

Limits require stable identity and scope. A customer organisation, user, delegated objective, agent run and downstream action need identifiers that survive retries and hand-offs. Resetting a session should not reset a spend mandate. Invoking another tool or agent should not create a fresh population allowance. If distributed systems cannot enforce a shared counter reliably, authority should remain below the level that depends on it.

Time limits include recurrence. An event-triggered agent can perform well once and still become unsafe when it continues after the business context changes. Standing schedules need start, end, renewal, quiet-period and change triggers. A supplier update, policy change or customer role change can pause the mandate even when calendar time remains.

Population limits constrain who or what can be affected. A recruitment copilot tested for one role should not expand across job families through a shared queue. A procurement agent approved for named vendors should not interpret a new subsidiary as equivalent. Explicit identifiers and eligibility rules are stronger than natural-language reminders.

Loss exposure combines reversibility, detection and response time. A low-value action repeated rapidly can exceed a single high-value approval. A reversible draft can become irreversible after publication or external reliance. The product should model the point at which interruption no longer outruns consequence and place the stop before it.

Observation, interruption and repairGive the retained human role enough leverage

Plan visibility should match initiative. An assistant can show sources and uncertainty for one response. A copilot should expose how shared context shaped a proposal and which files or records will change. A bounded agent should preview the objective, plan, tools, action classes, limits and checkpoints, then update the trace as the plan changes.

Evidence should support the user's decision rather than overwhelm it. Show the target, material facts, alternatives, counter-signals and effect. A developer reviewing a patch needs changed code, test result and unresolved risk. A procurement owner needs vendor, price, term deviations, authority consumed and remaining spend. Generic reasoning text is not a substitute for evidence from the product's operating context.

Interruption must stop the action path and reach a safe state. A pause button that stops new planning while queued tool calls continue is misleading. The contract identifies what can still complete, how partial actions are reconciled and how the user learns that interruption succeeded. Time to interrupt should stay below time to unacceptable consequence.

Recovery differs from rollback. Undo may restore product state but not retract a message, reverse external reliance or repair a person's outcome. The contract includes reconstruction, correction, appeal and remedy. It names whether the customer or provider performs the repair and which evidence proves closure. Commercial support and liability allocation should match that burden.

Memory requires a declared purpose and deletion. Workspace state for a repository should not become reusable customer memory. Copilot context from one customer or purpose should not contaminate another. Cross-session identity, retrieval and deletion need enforcement at storage, index, cache and derived-state layers. If the product cannot prove separation, the appropriate contract is narrower state or no delegation.

Negative controlsContracts the compiler must distinguish

Interactive instrumentProduct Contract Compiler

The Compiler turns customer outcome, task structure, state, tool and control choices into one product pattern with required clauses. It does not generate an autonomy, trust or maturity score.

Choose the least expansive contractProve each increase in initiative and authority

Offer a turn-based assistant when the user can frame and sequence the task, external action is unnecessary and short-lived context is enough. Its promise is to draft or answer within a supported use. The user executes, and the product does not imply that conversational fluency includes publication or commitment authority.

Offer a shared-context copilot when continuity and co-planning reduce coordination work while the person remains capable of sequencing, evaluating and committing. The contract protects purpose-scoped state, shows proposed changes and makes the retained human decision real. Repository access, for example, does not grant commit authority.

Offer a bounded delegated agent when dynamic steps and tools create customer value that an assistant or copilot cannot deliver efficiently. The objective, action classes, time, spend, volume, population, tool depth and exposure are enforced across the run. Plans and evidence remain visible, interruption reaches a safe state and recovery covers downstream effect.

Use deterministic automation when the state and rule are known. A probabilistic planner adds variation, explanation burden and operating dependency without adding judgement value. Normal software can still require access control, exception handling, monitoring and commercial support, but it should not be marketed as an agent to signal sophistication.

Do not delegate when consequence is irreversible, the objective cannot be bounded, material failure is not discoverable, evidence is weak, cumulative limits cannot be enforced or recovery cannot repair the outcome. A narrower proposal-only product may remain possible, but the unavailable control should not be replaced with confirmation theatre.

The names matter only after the clauses. Product, security, operations, risk and commercial leaders should review the same compiled contract. If the interface, token, support promise or supplier change tells a different story, the contract is broken. The product earns more initiative through outcome evidence and enforceable control, one dimension at a time.

Contract proofTest authority inheritance, state separation and effective control

Authority must survive composition without expanding

A product contract is tested at the seams between components. The user may authorise the product to compare suppliers, the product may call a search tool and the tool may use a third-party service. Each component can be technically permitted while the composed effect exceeds the original objective. The system should carry the delegated objective, customer identity, purpose, action class and remaining limits through every call. A callee receives the minimum subset it needs; it does not inherit the caller's whole token, memory or mandate.

Tool responses can also change the plan. An agent that discovers a cheaper supplier may propose a new vendor, jurisdiction or payment route. Discovery is not authorisation. The new fact should enter the visible plan and trigger the relevant boundary. If the vendor is outside the approved population, the agent can preserve evidence and ask for a new decision without gaining permission through its own reasoning.

Sub-agents create two accountability paths. The technical trace records which component planned, called and returned. The business trace records which delegated objective and authority justified the effect. Both need stable identifiers. A chain of internally successful calls is insufficient when no record connects the final action to the customer decision. The product should reconstruct the whole chain, including retries, parallel branches and suppressed outputs.

Failure should reduce authority. If an identity check, limit service, trace sink or policy decision is unavailable, the product should fall back to draft, simulation or no action. It should not reuse a cached standing mandate merely to preserve availability. A degraded contract can be useful when it is visible and the commercial promise explains what remains available.

Purpose binds memory and state

Persistent state is a product feature only when the customer can understand its purpose, scope and lifetime. A developer copilot may retain repository structure, accepted conventions and test commands for one workspace. It should not convert proprietary code into general memory for another organisation. A service copilot may remember an open customer case but should not carry sensitive details into an unrelated purpose because the same employee starts both chats.

Deletion should follow the state graph. Removing a visible conversation may leave embeddings, indexes, caches, tool records, derived preferences and downstream documents. The contract states which objects persist, which are required for security or audit, how purpose separation is enforced and what deletion can actually achieve. A promise to “forget” is unsafe when the product cannot enumerate its derived state.

Memory also changes user reliance. A system that appears to know prior work may be assumed to know a correction that was never saved, a policy that changed or a boundary that applied only to another project. The interface should show which memory objects influenced the current plan and allow the user to exclude or correct them. Confidence in conversational continuity should not substitute for versioned context.

Cross-session recurrence requires renewed identity and role. A user who originally authorised a task may change role, leave the organisation or lose access to the underlying asset. The recurrence should evaluate current identity, resource permission, business mandate and expiry before acting. The fact that the product remembers the objective does not keep the delegation alive.

Test whether confirmation changes the outcome

A meaningful confirmation presents a choice that the user is competent and authorised to make. It shows the action target, material difference from the approved plan, evidence, cumulative effect and remaining alternatives. The user can approve, narrow, reject or stop. The product records the scope of that choice so one click does not silently authorise later actions that look similar.

Approval quality should be observed. Measure how often users inspect evidence, change the plan, reject an action, interrupt execution and discover an error before consequence. A near-perfect approval rate can indicate good plans, but it can also indicate fatigue, poor information or organisational pressure. Sample decisions and interview users about what they believed the approval covered. Compare retained responsibility with their available time and skill.

Confirmation cannot repair a structural mismatch. If the product asks a non-expert to evaluate an opaque security change, the person remains nominally in the loop but lacks leverage. The contract may need a deterministic control, specialist review, lower authority or a different product pattern. Adding another warning increases friction without creating knowledge.

Interruption and recovery should be exercised, not inferred from controls. Tests need pending calls, partial writes, expired credentials, duplicated events and unavailable downstream systems. The team observes which actions finish after stop, whether counters reconcile and whether a customer can restore or remedy the external state. A successful user-interface pause is not enough.

Change is a contract event

A model update can alter decomposition, abstention or tool selection. A prompt change can alter how objectives are interpreted. A new connector can introduce execution where the product previously drafted. A supplier can change latency or evidence availability. Each change maps to the grammar dimensions it affects and states which cohort, control or commercial claim must be retested.

Compatibility includes user behaviour. Customers may learn shortcuts, rely on remembered context or expand the task beyond the original wedge. Product telemetry should distinguish unsupported use from a changed product promise, and support should not quietly normalise the expansion. A requested new authority class enters discovery with its own consequence and recovery evidence.

Commercial language should change when authority changes. An assistant promise to help prepare work differs from an agent promise to pursue an outcome. Availability, support response, incident handling, remedy, excluded use, customer responsibilities and supplier dependencies should match the compiled contract. A marketing label cannot disclaim behaviour the product visibly enables.

The product review therefore compares four artefacts: the interface users see, the technical permissions enforced, the business mandate recorded and the commercial promise sold. They should describe the same initiation, state, action and recovery boundary. Any mismatch is a release defect, not a documentation clean-up task.

Retire authority when its outcome no longer needs it

Authority can become unnecessary even when the product still works. A dynamic procurement process may settle into a stable reconciliation rule. A copilot may teach a user enough that persistent suggestions no longer add value. An agent may retain a standing mandate after transaction volume falls or a business process changes. Reviews should ask whether the verified outcome still requires the current initiative, memory and tool depth. Reducing authority is product improvement when it preserves value with less consequence and support burden.

Retirement should revoke credentials, schedules, memory access, queued actions and sub-agent paths, then reconcile any external state created under the mandate. Customers need evidence that recurrence stopped and a route for unresolved commitments. Historic traces may remain for legitimate audit, security or legal purposes under controlled retention, but they should not keep the operational contract alive. A future reactivation begins with current identity, purpose, limits, capability evidence and commercial terms rather than inheriting an old approval.

The simplest acceptance test is behavioural: can a customer accurately describe who starts the work, what the product remembers, which external state it may change, how much consequence can accumulate, where interruption takes effect and who repairs failure? If the observed product contradicts that answer, the contract has not compiled.

Migrate the contract without smuggling in authority

A product may earn a move from assistant to copilot or from copilot to bounded agent, but the migration is a new customer decision rather than a routine feature release. The product team should state which grammar dimensions change, which outcome improves and which new consequence appears. Existing customers keep the prior contract until identity, state, tools, limits, recovery and commercial terms are ready. Default-enabling a persistent memory or execution connector turns adoption into consent and makes the old evidence difficult to interpret.

Run the higher-authority pattern beside the current one for a bounded cohort. Compare completed customer outcomes, coordination effort, review demand, interruptions, errors, recovery and support cost. Observe whether people understand the changed initiation and commitment points, not only whether they use the feature. A customer who accepts a suggestion may still believe that every external action waits for approval. Scenario tests should include an expired mandate, a supplier timeout, a changed objective and an action that crosses the cumulative limit. The migration passes when enforced behaviour and customer understanding agree.

Rollback needs a product contract too. Disabling the new mode should stop recurrence, revoke the additional permissions, preserve necessary evidence and reconcile work already in motion. It should not delete the trace required to repair an external effect or leave a sub-agent with a live credential. Commercial teams must know which outcomes remain supported after rollback and how customers return to the lower-authority workflow. A failed agent trial can still yield a useful copilot when state and evidence improve the human decision without retaining execution authority. Treating that reduction as a designed route keeps product learning honest and prevents an autonomy label from becoming a one-way commitment.