01 / THE REQUIREMENT
What the system must handle
A product agent must understand the user and current product state, then act without gaining broad or ambiguous access
02 / THE ARCHITECTURE
How the pieces connect
Connect the agent to typed product tools, scoped identity, current state, relevant knowledge, and an approval step for consequential actions
03 / OPERATING MODEL
How the system behaves
The agent can answer, create, update, or coordinate within defined boundaries. Logs and evaluations make its behaviour reviewable
WHY THIS PATTERN EXISTS
The problem it solves
Most product teams do not lack an assistant that can talk. They lack an agent that can finish a task inside the product, with the same permissions the user has and none of the ambiguity of a shared integration token. This pattern exists to close that gap: the agent reads live product state through typed tools, decides against explicit boundaries, and writes back through the same API surface your own UI uses. Because every action is a typed tool call, it is logged, reversible, and testable.
COMPONENTS
What you are actually deploying
Scoped identity bridge
The agent never holds a service account. Every call carries the invoking user's identity and permission set, so an action the user could not perform is an action the agent cannot perform either. This removes the most common source of AI incidents in a product: privilege escalation through an over-broad integration.
Typed tool registry
Capabilities are exposed as a closed set of typed functions with declared inputs, outputs, and failure modes, rather than as free-form function calling against a database. The registry is versioned, so a schema change is a deploy and a regression test, not a production incident.
Live state context assembly
Before acting, the agent assembles the minimum state the task needs: the record, its permissions, recent history, and the relevant policy. Context is assembled deterministically rather than recalled from memory, which keeps behaviour reproducible across sessions.
Approval boundary
Consequential actions, anything destructive, financial, or externally visible, route to an explicit approval step with the intended change rendered for the user. Approval is a first-class state in the workflow, not a prompt asking the model to be careful.
Evaluation and trace layer
Every run is replayable: inputs, retrieved context, chosen tool, arguments, and outcome are captured. Behaviour is scored against a task suite before release and monitored against the same suite afterwards, so regressions surface before customers report them.
FAILURE MODES
How these systems break
Every one of these has been found in production during an incident review. They are listed here because the design is only credible if it names what it defends against.
Ambiguous tool surface
When an agent is handed a generic query endpoint instead of typed tools, it guesses at arguments and produces confident, unverifiable writes. The fix is narrowing the surface, not adding instructions to the prompt.
Stale context
Acting on context captured before a user changed a setting produces work that silently overwrites the change. State must be read inside the same step that writes.
Silent partial failure
A multi-step action that fails halfway must leave the record in a known state. Every write is idempotent and every partially applied step has a defined rollback.
Prompt-level safety
Instructions like act carefully cannot enforce a permission boundary. Boundaries belong in the tool layer where they are testable and cannot be argued with at runtime.
FIT
When to use this, and when not to
Use it when
- Users repeatedly ask the product to do something the API can already do, and the team is fielding support tickets about it.
- The task requires live product state: permissions, relationships, and history that cannot be summarised from documentation.
- The action is reversible or recoverable, so an incorrect step is an annoyance rather than a loss.
- You need a defensible answer to who did what, which means every action carries an identity and a log entry.
Do not use it when
- The operation is destructive and irreversible without a human in the loop, such as deleting production data or issuing financial transfers.
- The user base cannot yet tell an agent response from a human one, and brand or compliance risk makes that unacceptable.
- There is no deterministic API behind the capability. Without a typed tool surface there is nothing to constrain the agent to.
QUESTIONS
What teams ask before building this
How is a product agent different from a chatbot with API access?
A chatbot answers. A product agent acts: it reads live state, calls typed tools, writes changes back, and records an auditable trail. The difference is the tool surface, the identity model, and the fact that the action completes without the user relaying information.
What stops the agent from doing something destructive?
It cannot be instructed to be careful, because that is not a control. Actions are constrained at the tool layer: the registry exposes only permitted operations, each call carries the user's own permissions, and consequential actions require an approval step with the change rendered before it is committed.
Where does the agent's knowledge come from?
Two places. Live product state, read through typed tools inside the same step that acts, and a curated knowledge layer for documentation, policy, and reference material. Retrieval is deterministic and versioned rather than assembled ad hoc per request.
How do you know it is working after launch?
Every run is replayable and scored against a task suite that runs before release and continuously afterwards. Tool failures, approval rates, and correction rates are monitored as product metrics, not just as logs.
DEPLOYED THROUGH
Capabilities that build it
APPLIED IN