Glossary
The 21 terms this site uses, each in a sentence or two of plain English. Underlined terms on other pages link here.
- Acting identity#
The account whose permissions the agent uses when the agent acts. The account might be the person’s own, a separate agent account, a shared connection someone else set up, or a service account. The acting account isn’t always the person chatting with the agent, so products should show which account acts.
- Approval#
A person’s agreement to one specific proposal: these items, these changes, this account doing the work. An approval records a decision about what the person saw. An approval doesn’t give the agent permissions the agent lacked, and doesn’t cover things that changed after the review.
- Capability#
A job the agent can do for a user, described as an outcome (“prepare a campaign for this segment”), not as a list of functions. A tool is one action the agent can call, like “pause campaign”; one capability may need several tools plus a review step and a result check. A good capability has one owning team, clear permissions, and a shared meaning of “done.”
- Delegation#
Handing a piece of work to an agent while a person stays responsible for the result. Linear makes delegation concrete: an issue can have a human assignee and a separate agent delegate. The agent may act with someone else’s permissions or its own. Salesforce’s customer-facing agents run as a designated agent user, not as the customer.
- Durable run#
Agent work the product saves, so the work survives a closed tab, a restarted server, or a new device. Each run and each change inside the run has a stable ID, so people can come back later and see what’s done, pending, or uncertain.
- Handoff#
Passing a conversation or job from the agent to a person or team. Announcing a handoff isn’t the same as someone receiving the work: the next person needs the work and enough context not to start over.
- Harness#
The machinery around an AI model that lets the model act: context and objects, the acting identity and its permissions, the screens where people review a change, and the receipts, history, and undo. For a product agent, the product is most of the harness; the model is the engine inside it.
- MCP#
Model Context Protocol: an open standard for connecting AI tools to other products. An outside AI app connects to a product’s MCP server, the part of the product that exposes the product’s actions, to discover and call those actions. MCP moves where a request starts; the product still decides what’s allowed and records what happened. A valid connection doesn’t mean every action is allowed.
- Operation ID#
A stable identifier for one intended change, kept when the job is retried, resumed, or taken over. The ID lets the product ask “did this exact change happen?” instead of guessing.
- Product agent#
Daniel’s working definition: an AI agent built into a software product that uses the product’s context and capabilities to carry out work for users, within the product’s permissions and controls. The work can be a change, a draft, or an answer based on current product data.
- Proposal#
The specific change the agent plans to make, shown for review before the change happens: which items, which fields, which values. A good proposal is saved with an ID and a version, so the approval and the actual run refer to the same thing.
- Receipt#
A record, produced by the system that made the change, of what actually happened: which items, the before and after values, the outcome, and the evidence. A receipt is different from the assistant saying “Done,” which is only a claim.
- Regression case#
A saved example of a past failure, with the starting state and the expected result, rerun whenever the agent changes so the same bug doesn’t come back. A regression case is one kind of eval: a check of the agent’s behavior against a defined expectation. A monitor flags suspect live runs; a grader (code, a person, or another AI model) decides pass or fail, and needs checking too. A fix is proven on held-out cases, kept aside and never used to build the fix.
- Resolution#
A support metric for conversations the agent is counted as having solved. Vendors define resolution differently: Intercom separates confirmed from assumed resolutions, and HubSpot sets resolution status 72 hours after the visitor’s last response. Deflection, a conversation handled without a person, can include customers who left without an answer. Before comparing two rates, check what each rate is divided by: the same 300 outcomes are 30% of 1,000 conversations or 50% of 600.
- Retry#
Trying a change again after the change seemed to fail. A retry is risky when the first attempt may have worked and only the reply was lost. Idempotency means repeating a request doesn’t repeat the effect: the destination recognizes the operation ID and returns the original result instead of making the change twice.
- Stale proposal#
A proposal whose facts changed after someone reviewed the proposal: a new item matches, a record was edited, or access was revoked. The product should refuse the stale proposal, report the conflict, or ask for a fresh review instead of running the proposal anyway.
- Standing instruction#
A rule that lets the agent act later without asking each time, like “every morning, prepare new dates for overdue draft tasks in this project.” A trigger, an event or a schedule, starts the work; an agent that starts work this way is a proactive agent. A good standing instruction names the trigger, scope, acting account, limits, and owner, and the product checks permission again when the rule fires.
- Trace#
A step-by-step record of how an agent handled one request: model calls, retrieved data, tool calls, and results. Each recorded step is a span. Traces show where things went wrong, like the model receiving the right campaign ID but pausing a different campaign.
- Undo#
A new action that tries to reverse an earlier action. Restoring a value is different from reversing the value’s effects, like a notification already sent. An honest undo says what the undo will change and leave behind, and skips records someone edited since. Stop and Cancel only halt further work: neither reverses changes already made, and a cancel request has an outcome of its own.
- Verified outcome#
A result someone has checked against a clear definition of done, using the changed record, a receipt, or a review with a rubric. The site uses verified outcomes as the unit for measuring cost and success.
- Version check#
Comparing a record’s version number, not just the value, before changing the record. A date changed from Friday to Monday and back to Friday looks untouched by value, but the version shows someone edited the date.