Agent Operability · A field guide for enterprise AI & technology leaders · First edition, July 2026
Why your workflows — not your models — decide whether agents work.
Can the agent consume authoritative context?
What should it read, draft, decide, or execute?
As whom does it act, and who answers?
A capable agent inside an inoperable workflow is still an inoperable system.
For forty years, enterprise software assumed that a human would be present at the decisive moment: reading the screen, interpreting the exception, choosing the next step, and carrying the accountability. AI agents change that assumption.
The moment software can remember context, choose among options, call tools, and initiate action, the design problem is no longer limited to the interface. It becomes a question of delegation: what work can move, what authority can travel with it, what evidence must be left behind, and how a human recovers control.
auxfirst calls the wider discipline Agentic Experience Design (AUX). AUX designs the enduring relationship between people and systems that remember, adapt, and act. Trust is not a feature added at the end. It is the operating condition that makes delegation possible.
This field guide applies that point of view to the enterprise itself. It introduces agent operability: a practical way to assess whether a workflow can be safely and repeatably operated by an agent, rather than merely observed or summarized by one.
The pilot looked excellent in the demonstration.
A procurement agent could read an incoming vendor questionnaire, locate prior answers, pull the right policy language, identify gaps, and produce a response pack in minutes. The model was capable. The retrieval worked. The output was cleaner than the team expected. The sponsor could see weeks of effort disappearing from the process.
Then security asked a basic question.
What account will the agent use?
The room went quiet.
The workflow crossed five systems. The procurement analyst could access three of them. Legal could access two. Information security could see the policy repository but not the commercial records. A senior manager could approve exceptions, but only inside a separate ticketing flow. No individual human had the combined access the agent would need to execute the workflow end to end.
Someone suggested using the procurement lead's login. Someone else suggested a shared service account. The pilot team said the agent could simply ask a human whenever it reached a protected step. Security asked how the handoff would be logged, how privileges would expire, how data would be isolated between cases, who would own the output, and whether the agent could distinguish a routine exception from a legally material one.
There were no answers — only implementation ideas.
The pilot did not fail because the model hallucinated. It did not fail because the prompt was weak. It failed because the enterprise had treated the workflow as a sequence of screens rather than a system of data, decisions, authority, and accountability.
That is the pattern now repeating across organizations. Agents perform well in a bounded demo because the demo quietly removes the difficult parts. The data is preselected. The exceptions are controlled. Permissions are borrowed from the person running the test. The outputs remain drafts. The cost of being wrong is low because nothing has actually moved.
Production puts the difficulty back in.
The agent meets inconsistent records, missing fields, old policies, ambiguous ownership, undocumented judgment, conflicting incentives, and tools that were designed for a person with a browser. It needs access that no single role currently holds. It encounters an exception whose meaning exists only in the memory of one experienced employee. It creates an output that is technically generated by software but commercially owned by the company. Suddenly, the model is the least interesting part of the system.
Enterprise AI discussions often begin with capability: which model reasons best, which platform orchestrates agents, which vendor has the strongest roadmap. Those choices matter. But capability is not operability.
A forklift can lift more than a person. That does not make every building forklift-operable. The aisles need clearance. The floor needs load capacity. The goods need pallets. The operator needs rules. The route needs barriers. The organization needs to know who is responsible when the machine moves something it should not.
Agents create the same distinction for knowledge work.
A workflow is agent-operable when an agent can perform an explicitly defined share of the work with the data, authority, controls, evidence, and human handoffs required to make the result safe, repeatable, and answerable.
That definition matters because it moves the question away from "Can the model do this task?" and toward five more useful questions:
Agent operability is not a binary certification. It is a property of a particular workflow, for a particular agent, under particular conditions. The same agent may be operable for preparing an internal summary and inoperable for sending a customer commitment. The same workflow may be operable in one region and blocked in another because the systems, regulations, or ownership differ.
This is why enterprise-wide claims such as "we are agent-ready" are usually too vague to be useful. Operability lives at the level where work actually happens: the workflow, the action, the data object, the decision right, and the permission.
Most pilots are framed as software implementation projects. A team selects a model, connects several sources, adds a user interface, and measures output quality. But an agent is not merely another interface to the workflow. The agent becomes an actor inside it.
That changes the design object.
Classic UX asks: can a person complete the task efficiently? AUX asks: what will a person permit a system to do on their behalf, how does that permission expand or retract, and how does control return when the system is uncertain or wrong?
Agent operability extends the same logic to the enterprise operating model. It asks whether the organization itself is legible and accessible enough for a non-human actor to participate without borrowing invisible human infrastructure.
That invisible infrastructure includes:
Agents do not inherit this infrastructure automatically. It must be exposed, structured, bounded, and governed.
This book organizes the problem into three layers:
The three layers behave like a weakest-link system. High-quality data cannot compensate for an undefined approval boundary. A beautifully mapped process cannot compensate for inaccessible context. Strong identity infrastructure cannot rescue a workflow whose critical judgment remains undocumented.
Agent operability is not the average maturity of the three layers. It is the lowest maturity among them.
The rest of this book builds the vocabulary and tools needed to work on that lowest layer deliberately.
The public conversation about enterprise agents has changed.
Two years ago, the most common questions were about model capability: whether a model could reason over long documents, use tools, or produce acceptable work. Today, enterprise technology leaders increasingly describe a different bottleneck. The models are capable enough to expose how unprepared the surrounding organization is.
In July 2026, Box CEO Aaron Levie summarized themes from a dinner with leaders responsible for agent adoption in large enterprises. The recurring topics were not prompt engineering or model benchmarks. They were change management, the need to modernize operating models, and the unglamorous work of making structured and unstructured data usable by agents. The significance is not that one dinner discovered a universal truth. It is that the same pattern is now recognizable across organizations: the agent is often ready before the workflow is.
Three ideas are converging.
Traditional enterprise software implementation often separates the technical build from adoption. The system is configured; then training, communications, and change champions help people use it.
Agents blur that separation because adoption depends directly on how authority is designed. Employees are not merely learning a new tool. They are deciding whether to delegate work to a system that may remember, recommend, and act. Their trust depends on whether the agent's intent is visible, whether it asks before consequential actions, whether it can be corrected, and whether mistakes create recoverable or irreversible consequences.
A technically functioning agent with an unclear control model creates rational resistance. People are not "change resistant" because they refuse to approve invisible delegation. They are responding to an operating model that has not made the new relationship legible.
This is a central AUX principle: trust is dynamic. Autonomy expands with evidence and retracts with violation. Adoption therefore cannot be treated as a communication layer placed on top of the system. The rules by which trust is earned must be designed into the workflow.
The enterprise data conversation was built around analytics, reporting, and machine learning. Agentic work imposes a different standard.
A dashboard can tolerate a field whose meaning is known by the analyst. A retrieval system can return a policy document without understanding whether it is superseded. A search result can expose five relevant sources and leave a human to reconcile them.
An acting agent needs more. It needs the right context for the specific decision, at the right moment, with enough provenance and structure to know what can be trusted. It needs to distinguish policy from commentary, current from obsolete, global from market-specific, approved from draft, and instruction from evidence.
This is why "we have the data" is often true and insufficient. The information exists, but its operational meaning is carried by folders, naming conventions, social knowledge, inbox history, and human interpretation.
The real prerequisite is not merely access to data. It is shaped context.
For decades, many business workflows could be changed locally. A team adopted a new application, redesigned a process, or added automation within its function. Agents cut across those boundaries because useful work often requires context and action from several systems at once.
A customer onboarding agent may need CRM data, contract terms, identity verification, billing status, product configuration, support history, and communications. A campaign QA agent may need brand policy, market rules, asset libraries, media plans, analytics, and publishing access. The workflow is commercial, but its operability depends on identity, integration, policy enforcement, logging, and lifecycle management.
That moves IT from support function to operating-model architect. It also makes the old split between "business process" and "technical architecture" increasingly artificial. The agent experiences both as one environment.
The enterprise market has many mature vocabularies around adjacent problems:
Agent adoption touches all of them but belongs fully to none of them. This creates coordination problems.
The data team says the source is available. The process owner says the workflow is documented. Security says the system can use a service account. The AI team says the model passes evaluation. Yet nobody can answer whether the workflow is safe to delegate at the action level.
Agent operability provides a shared object for those teams to inspect together.
It does not replace existing disciplines. It connects them around the specific question: what must be true for this agent to perform this part of this workflow under real enterprise conditions?
The phrase "AI use case" is too broad. It groups together a chatbot that summarizes a document and an agent that changes a production record, even though the operating requirements are entirely different.
A better framing is the delegation case. A delegation case specifies:
This framing changes portfolio decisions. Instead of ranking ideas by excitement or theoretical time saved, leaders can rank delegation cases by value, operability, and heat.
The best first workflow is often not the most impressive one. It is the workflow where the organization can learn the operating discipline without placing trust under maximum load.
Across agent pilots, the same sequence appears:
The wrong conclusion is drawn from the right evidence. The agent may be ready. The workflow is not operable.
Agent operability makes that diagnosis actionable. It separates model limitations from organizational limitations, and it shows which layer must move before more engineering effort will create value.
Agent operability is the capacity of a workflow to be performed by an agent with bounded autonomy, usable context, explicit decision rights, and reconstructable accountability.
The model has three layers — and the weakest layer sets the maximum safe autonomy:
| Layer | Core question | Typical failure |
|---|---|---|
| 1 · Data shape | Can the agent consume the context required to do the work correctly? | Information exists but is ambiguous, stale, inaccessible, or dependent on tribal knowledge. |
| 2 · Process design | What should the agent read, draft, decide, or execute — and where must a human intervene? | The documented process omits exceptions, judgment, and real handoffs. |
| 3 · Trust & permissions | As whom does the agent act, within what boundary, and who answers for the result? | Borrowed logins, over-broad service accounts, unclear authorship, and no durable evidence trail. |
Organizations often invest in the layers unevenly.
Layer 1 receives the most attention because data programs already exist. Layer 2 is improvised through workshops and automation diagrams. Layer 3 is postponed until security review, when it becomes a blocker rather than a design input.
But the layers do not add together like points in a maturity score. They multiply — and a near-zero score in one layer collapses the delegation case.
Operability = minimum(Data Shape, Process Design, Trust & Permissions)
This is not a mathematical claim. It is an operating rule. The weakest layer sets the maximum safe autonomy.
Consider a vendor compliance workflow:
The workflow is not highly operable. Its permission model caps it.
Now reverse the problem:
The workflow is still not highly operable. Its data shape caps it.
Data shape asks whether the information the workflow depends on is prepared for action, not merely available for reading. This includes:
The final dimension is what separates readable from operable. A policy PDF is readable. A policy clause with an owner, jurisdiction, effective date, supersession status, exception rule, and linked approval path is operable.
Process design asks what the work actually is. Most enterprise workflows have at least three versions:
Agents meet version three.
An agent-operable process map must capture: triggers and success conditions; human, system, and agent actors; inputs, intermediate artifacts, outputs, and audit artifacts; decision points and the evidence used at each one; routine paths, exceptions, dead ends, retries, and escalation paths; action heat and required control posture; ownership of each handoff; and measurable quality, trust, and economic outcomes.
The central design choice is delegation. Every action must be placed deliberately across a spectrum from observation to autonomous execution. auxfirst expresses this through two related models:
Autonomy should fit heat. It should not simply increase because the model becomes more capable.
Trust & permissions asks whether the agent has a legitimate place in the organization's system of identity, authority, and accountability.
A production agent needs more than credentials. It needs an operating contract. At minimum, the organization must define:
The trust layer is not equivalent to security. Security protects systems and information. Trust architecture makes delegated action legible and answerable to people.
An agent can be secure in the narrow technical sense and still be untrustworthy in operation. It may authenticate correctly while acting beyond the user's intent. It may access only permitted records while using stale context. It may produce an accurate draft whose authorship and approval status are unclear.
Trust emerges from the combination of capability, boundaries, evidence, control, and accountability.
A practical assessment begins with one workflow and one target delegation case. For each layer, ask:
The output should not be a generic maturity score. It should be a map of the workflow showing where operability breaks. A useful map contains four views:
This is deliberately narrower than an enterprise AI strategy. The purpose is not to describe everything the organization should become. It is to make one delegation case buildable, governable, and economically defensible.
Imagine an agent that reviews invoices, matches them to purchase orders, and routes exceptions.
Data shape gap: supplier names are inconsistent, purchase orders are missing line-level references, and approval limits are stored in a spreadsheet maintained by one finance manager.
Process design gap: "routine discrepancy" is not defined. Experienced analysts use different thresholds based on supplier history and urgency.
Trust & permissions gap: the agent can read invoices and purchase orders but would need authority to change payment status and contact suppliers. No dedicated identity or communication approval model exists.
The first operable version should not autonomously resolve exceptions. It should:
This is less autonomous than the original vision and more valuable than a stalled pilot. Operability often advances by cooling the action, not by forcing the organization to accept more risk.
Do not ask how autonomous the agent can be. Ask what level of autonomy the workflow has earned.
Enterprises contain enormous amounts of machine-readable information. That does not mean agents can use it to operate workflows.
The distinction begins with a simple observation: humans read with context they do not notice they are supplying.
An experienced employee opens a file and immediately recognizes that it is old. They know that "final" does not mean final in this team. They understand that a certain customer category requires a different approval path. They see an empty field and infer that the value lives in an email thread. They know which manager's comment should be treated as a decision and which is merely a suggestion.
The document did not contain all of that meaning. The employee brought it.
Agents expose this gap because they require the organization to externalize enough context for the action to be justified and repeatable.
The following maturity ladder is designed for workflow operability, not for general data governance.
| Level | Description | What the agent can safely do |
|---|---|---|
| D0 · Human-located | Information exists across screens, inboxes, folders, and memory. | Observe only with heavy human guidance. |
| D1 · Machine-retrievable | Sources can be searched or fetched, but authority and meaning remain ambiguous. | Summarize and surface candidates. |
| D2 · Machine-interpretable | Key fields, taxonomies, versions, and relationships are explicit. | Classify, compare, and draft with cited evidence. |
| D3 · Action-linked | Context is connected to rules, states, and permitted next actions. | Recommend and execute bounded, reversible steps. |
| D4 · Governed context | Provenance, freshness, scope, retention, and policy are continuously enforced. | Operate repeatably within a defined permission envelope. |
The maturity required depends on the heat of the action. A low-risk internal summary may be acceptable at D1. A customer commitment or financial action may require D3 or D4.
The common distinction between structured and unstructured data is useful but incomplete.
A database field can be structured and operationally meaningless. A well-governed policy document can be unstructured and highly operable. The important questions are not only how the information is stored, but whether the agent can determine:
This is why data shape includes both technical structure and organizational semantics.
Tribal knowledge is often discussed as a documentation problem. For agents, it is more than that. It is hidden execution logic.
Examples include:
These statements change actions. If they remain in people's heads, the agent either fails or forces a human to reinsert the missing context at every run.
The goal is not to document every tacit nuance before starting. That would create an endless knowledge-management program. The goal is to identify load-bearing judgment: the hidden knowledge whose absence changes a consequential action.
One of the most valuable sources of context is the residue of prior decisions.
A policy tells the agent what should happen in general. Historical decisions show how the organization interprets the policy under real conditions.
But raw history is dangerous. Past decisions may be inconsistent, biased, obsolete, or based on facts no longer visible. The agent should not blindly imitate them.
The useful pattern is to transform selected decisions into governed examples containing:
We call this decision residue: structured traces of how judgment was applied, retained as context without pretending that precedent is universal policy.
Retrieval systems often optimize relevance. Operability requires authority.
The most semantically similar document is not necessarily the one that should govern the action. Agents need an authority model that can distinguish:
A practical authority model can be simple. Every critical source should carry metadata for owner, status, effective date, scope, supersession, and review date. The agent should be instructed — and technically constrained where possible — to prioritize sources according to that hierarchy.
When authority conflicts, the correct behavior is usually not "choose the most likely answer." It is "surface the conflict and escalate." Graceful uncertainty is an AUX heuristic because confident resolution of ambiguous authority is one of the fastest ways to destroy judgment trust.
A common response to missing context is to provide the agent with everything.
This can reduce quality rather than improve it. Irrelevant or conflicting context increases the chance that the agent will focus on the wrong source, blend scopes, or carry outdated information into the decision.
Context should be treated as an allocation problem. The agent needs the minimum sufficient context for the current action, selected according to explicit relevance and authority rules.
Useful controls include:
This is context efficiency: using context intelligently, not exhaustively.
Consider a pricing policy stored as a PDF.
The PDF may be sufficient for a human to read. To become operable, the critical parts could be represented as a knowledge object with:
The PDF remains the authoritative source. The knowledge object makes its operational meaning available to the workflow.
Do not begin by "cleaning all the data." Begin with the actions the agent is expected to perform.
For each action, identify:
This keeps the work bounded. A three-week operability audit should not become a multi-year data transformation. It should produce a prioritized fix list tied directly to the workflow and the level of autonomy being pursued.
The full scored assessment for this layer — 12 items, aligned with the audit methodology — is in Appendix A.
An agent does not need all your data. It needs the right context, with enough authority and structure to justify the next permitted action.
A workflow is not a list of tasks. It is a chain of actions with different consequences.
The distinction matters because agents are often discussed at the capability level: "the agent can handle onboarding" or "the agent can manage RFPs." Those phrases hide the actions that create risk. Reading an RFP, extracting requirements, drafting an answer, selecting a commercial commitment, and submitting the response are not one capability. They are five different action classes with five different control requirements.
Agent process design begins by breaking the workflow into verbs and objects: read policy; retrieve customer history; classify requirement; draft response; recommend exception; approve discount; send commitment; update system of record.
Once the actions are visible, the team can decide what should move to the agent and at what temperature.
For operability design, every workflow step can be placed into one of four plain-language modes:
Observes, retrieves, summarizes, classifies, monitors. Doesn't change business state — but reading can still expose sensitive data. Read-only is a permission posture, not a guarantee of safety.
Creates a proposed artifact for human review. One of the most powerful de-escalators: most of the productivity value, zero exposure until a human acts.
Selects among options, applies a rule, routes, approves, refuses. Needs evidence and explicit boundaries — can "right" be checked, and is it inside the policy envelope?
Changes state: sends, publishes, pays, deletes, deploys, signs, grants, books, commits. Needs identity, authority, limits, evidence, and a recovery design.
These modes are not a maturity ladder where execute is always the goal. The correct design may permanently keep a step at draft or decide. The objective is not maximum autonomy. It is the best human–agent allocation for the stakes.
auxfirst's Action Heat Ladder turns the vague question "is this risky?" into a repeatable reading. Every agent action is scored across five dimensions from 0 (cool) to 4 (hot):
| Dimension | Question | Cool end | Hot end |
|---|---|---|---|
| Reversibility | Can we take it back? | Fully undoable | Permanent or unrecoverable |
| Blast radius | How far does it spread? | One item | Whole estate or population |
| Exposure | Who sees it? | Stays inside the working loop | Public, customer, regulator, press |
| Commitment | What does it bind us to? | No promise or value movement | Legal, financial, or reputational commitment |
| Authority | What is it allowed to touch? | Read-only or sandbox | Production, identity, and access control |
An action is as hot as its hottest dimension. Four cool dimensions do not cancel one hot one.
A routine invoice email may be highly reversible and narrow in scope, but it leaves the organization and requests payment. Exposure and commitment make it a high-heat action.
Heat should change who pulls the trigger.
| Heat band | Default control posture | Meaning |
|---|---|---|
| Low | Auto-run | The agent may execute and log. |
| Low–medium | Auto-run + sampled review | The agent executes within limits; humans audit a sample. |
| Medium | Propose + approve | The agent prepares the action; a human approves the commit. |
| High | Named approver | A specific accountable role must authorize each action. |
| Critical | Human executes | The agent may assist, but a human performs the action in the authoritative system. |
The bands are not universal laws. They are a starting policy. Regulated environments, vulnerable populations, or high-value transactions may require stricter controls.
High heat does not automatically mean "do not use an agent." It means redesign the action. Six common de-escalators are especially useful:
This is the practical route to safe autonomy. The team does not debate whether agents are trustworthy in the abstract. It changes the action until the required trust fits the evidence available.
RFP response is a useful example because it combines data retrieval, judgment, cross-functional access, commercial commitment, and external communication.
A sales lead receives the RFP and forwards it to a bid manager. The bid manager creates a folder, copies an old response, and asks subject-matter experts for input. Security answers a questionnaire from its own library. Legal reviews clauses. Finance approves pricing. An executive approves non-standard commitments. The bid manager reconciles versions and submits through a portal.
The official process may show six steps. The real process contains dozens of micro-decisions: Is the opportunity worth pursuing? Which prior response is safe to reuse? Has the policy changed since the prior answer? Does the requirement ask for a current capability or a roadmap promise? Which claims require evidence? Which clause creates a non-standard obligation? Is the price inside the approved corridor? Who can approve an exception before the deadline?
Agent actions: ingest RFP, classify requirements, identify deadlines, map questions to owners, flag missing artifacts. Heat: low to low–medium — internal and mostly reversible, but the agent may access confidential documents. Control: auto-run with logging and source restrictions. Data-shape requirement: the RFP, response library, policy sources, owner directory, and current capability catalog must be retrievable and scoped.
Agent actions: find approved claims, certifications, case studies, policy language, prior answers. Heat: low–medium — no external action, but context leakage and stale evidence are material risks. Control: auto-run from approved repositories; show provenance and freshness. Design requirement: separate authoritative evidence from persuasive examples. The agent must never convert a roadmap item into a current claim.
Agent actions: produce answer drafts, cite sources, mark confidence, identify questions that require human input. Heat: medium — not yet external, but it shapes a commercial artifact. Control: propose + approve by question owner or bid manager. Trust patterns: Confidence Cues, Progressive Transparency, and Loop In Experts — the draft should expose evidence without burying the reviewer in raw context.
Agent actions: classify each requirement as compliant, partially compliant, planned, exception required, or cannot meet. Heat: high for ambiguous requirements — the classification can create legal and commercial consequences even before submission. Control: the agent may recommend; named owners decide exceptions. Process requirement: the categories and evidence thresholds must be explicit. "Partially compliant" cannot be a stylistic judgment.
Agent actions: propose pricing, delivery assumptions, service levels, contractual deviations. Heat: high to critical — commitment and exposure are high. Control: agent drafts; finance, legal, and executive approvers authorize according to thresholds. The agent does not independently sign or submit non-standard commitments. Permission requirement: the agent may read approved pricing corridors and clause libraries but cannot change approval limits or create new contractual authority.
Agent actions: package files, validate completeness, upload through the buyer portal. Heat: high — submission is external, often irreversible after the deadline, and binds the company to the response. Control: named human approves the final package. Depending on policy, the agent may upload after approval or the human may execute the submission. Authorship requirement: the package must record the agent version, evidence sources, question owners, approvals, and final submitter.
The target process is not "the agent writes the RFP." It is a designed allocation:
| Workflow segment | Agent owns | Human owns |
|---|---|---|
| Intake | Decomposition, routing, deadline extraction | Pursuit decision |
| Evidence | Retrieval, source matching, freshness checks | Authority conflict resolution |
| Drafting | First drafts, citations, gap flags | Claims approval and nuance |
| Compliance | Recommendation against explicit criteria | Exceptions and material interpretation |
| Commercial | Scenario preparation inside corridors | Commitments, deviations, approval |
| Submission | Completeness validation, packaging, optional upload | Final authorization and accountability |
This model is more useful than a percentage automation target. It makes the boundaries visible and gives the organization a path to expand autonomy later if evidence supports it.
Teams often overestimate the amount of judgment in a workflow because experienced people perform routine pattern matching fluently. They also underestimate judgment because the process map labels a step "review."
To distinguish load-bearing judgment from habit, ask:
If the answer is no, the step may be mechanical and suitable for greater automation. If yes, the design should preserve human accountability or deliberately build a stronger decision policy and evidence base.
A static process map is not enough. Agents run in time. The runtime design should specify:
Many "model failures" in production are runtime failures: the agent retries a payment, sends a duplicate message, acts on stale state, or cannot recover after one tool call fails.
Map actions, not aspirations. Heat each action. Then give the agent only the autonomy that the action and evidence can carry.
The permissions problem appears late because pilots borrow authority from humans.
A developer runs the agent using their credentials. A process owner uploads the files. A tester confirms every tool call. A shared integration account connects the systems. The demo works because the human operator quietly provides the identity, judgment, and access model.
Production removes that convenience. The agent must operate repeatedly, across users and cases, with access that is discoverable, reviewable, revocable, and proportionate to the work.
This is not solved by giving the agent "a service account." A service account is an implementation mechanism. Agent operability requires an identity model.
Enterprise access is usually organized around people, applications, teams, and job roles. An agent may not fit any one of them.
Consider a customer onboarding workflow. The agent may need to: read the signed contract; verify account and billing information; create records in CRM and product systems; request missing compliance documents; schedule implementation tasks; notify internal owners; monitor completion; escalate exceptions.
No single employee may hold all of these permissions. That is often intentional. Segregation of duties prevents one person from controlling the entire chain.
If the agent is granted the union of everyone's access, it can become more privileged than any human. If it acts under one user's identity, accountability and policy become misleading. If it asks humans to perform every protected step, the workflow may preserve all the friction the agent was meant to remove.
The answer is not to copy the human role model. It is to define the agent as a governed actor with its own bounded role.
The Agent Identity Card is the human-readable artifact that defines who the agent is inside the organization.
It should be understandable by security, IT, legal, the process owner, and the business sponsor. It is not a credential file. It is the agent's organizational identity and operating contract at a glance.
| Field | What it defines |
|---|---|
| Agent name and ID | Unique, discoverable identity. |
| Purpose | The business outcome and workflow the agent exists to support. |
| Sponsor | Human accountable for the identity lifecycle and access. |
| Product owner | Human accountable for behavior, roadmap, and outcomes. |
| Process owner | Human accountable for workflow truth and exceptions. |
| Scope | Business unit, region, customer class, and environments covered. |
| Data domains | Sources the agent may read, with restrictions. |
| Tools and systems | Named capabilities the agent may call. |
| Action classes | Read, draft, decide, and execute actions permitted. |
| Permission envelope | Limits, conditions, caps, and prohibited actions. |
| Trust stage | Functional, contextual, judgment, or advocacy trust earned. |
| Escalation path | Who receives which uncertainty or exception. |
| Memory policy | What persists, where, for how long, and editable by whom. |
| Authorship policy | How outputs disclose agent, evidence, and approval. |
| Audit and review | Log location, access review cadence, expiry, and rollback owner. |
The Identity Card is deliberately one page. It creates a shared reference before technical teams encode the details into IAM, policy engines, tool manifests, and runtime configuration.
Purpose: Reduce response cycle time while preserving claim accuracy and approval accountability.
Sponsor: VP Commercial Operations · Product owner: Head of Bid Management · Process owner: Director of Enterprise Sales
Environment: EMEA enterprise bids; production response workspace only
Trust stage: Contextual trust earned; judgment trust limited to low-ambiguity classifications
May read: approved policy library, certifications, product capability catalog, selected prior responses, opportunity record, approved pricing corridors.
May draft: response text, compliance classification recommendation, evidence list, clarification questions, submission checklist.
May decide: routing, question ownership, duplicate detection, low-risk requirement taxonomy.
May execute: create workspace, assign tasks, update internal status, package approved documents.
May not: approve exceptions, create non-standard commitments, change pricing, send external clarification, submit final response without named approval.
Limits: one opportunity workspace at a time; no cross-client memory; no access to HR or unrelated customer records; external communication disabled; all source documents must carry approved status.
Escalates to: Security for unsupported claims; Legal for clause deviation; Finance for pricing outside corridor; Bid Lead for authority conflict.
Review: quarterly access review; automatic expiry after 180 days without sponsor renewal; immediate pause after high-severity trust incident.
This card gives the security team something concrete to review. It also exposes design gaps before implementation. If the team cannot complete a field, the workflow is not ready to grant that form of delegation.
A permission is usually described as access to a resource: read this database, write that record, call this API. An agent needs a richer construct because the same tool may be safe or unsafe depending on context.
The permission envelope is the bounded combination of:
A useful permission statement is therefore not: "The agent can update CRM records."
It is:
"The agent may update the onboarding-status field for accounts in the EMEA implementation queue after contract validation succeeds, for up to 50 accounts per run, with every change logged and any conflicting account state routed to the implementation owner."
The second statement can be reviewed, encoded, tested, and audited.
Agent identity systems increasingly distinguish two operating modes.
The agent acts as a distinct principal. Its permissions are tied to its role and lifecycle. This is appropriate for persistent process agents performing a defined organizational function: monitoring queues, reconciling records, preparing reports, or executing bounded operational actions. Benefits include clearer accountability, stable least-privilege design, and access that does not depend on one employee remaining in role.
The agent acts within the user's authorization context for a specific request. This is appropriate when the action represents the user's intent and should not exceed the user's own rights: searching personal files, drafting within a user workspace, or initiating an action the user is authorized to perform.
The critical design question is whether the agent may combine its own organizational authority with user-delegated authority. That combination can create unexpected privilege. The delegation chain must remain visible in the audit trail.
Borrowing a human identity creates several problems:
The convenience is temporary. The accountability debt is permanent.
Agent governance becomes vague when one person is described as "the owner." At least three accountabilities should be separated:
A fourth role, the trust owner, may be explicit in larger programs. This person is accountable for adoption, autonomy boundaries, experience patterns, and whether trust is being earned or eroded.
Named human accountability does not mean humans approve every action. It means the organization knows who is responsible for the system's continued operation and for changing its boundaries.
Trust and permission are related but not identical. auxfirst's trust ladder has four stages:
An agent may have broad technical permission but low earned trust. That is a dangerous state. It may also have high demonstrated reliability but intentionally narrow permission because the action is high heat.
The Identity Card should record both: the trust stage earned through evidence, and the permission envelope granted for this workflow. The gap between them is informative. If permission exceeds earned trust, risk is being assumed. If trust greatly exceeds permission, the organization may have an opportunity to unlock value safely.
Human access programs already recognize joiner, mover, and leaver events. Agents need equivalent lifecycle controls. An agent identity should have:
The identity should not outlive the delegation case that justified it.
An agent needs more than credentials. It needs a name, a sponsor, a bounded role, an expiry, and a trail that shows when it acted as itself and when it acted for someone else.
Security asks whether the system is protected. Trust architecture asks whether delegated action can be understood, challenged, reconstructed, and owned.
The distinction becomes important when the actor is software.
A human-authored document carries familiar social signals. The author has a role, reputation, manager, and employment relationship. Colleagues may know how the person reached the conclusion. If the output is wrong, the organization has processes for correction and accountability.
Agent output can look equally polished while its origins are opaque. Which model produced it? Which sources were retrieved? What policy version applied? Was the agent acting under a user's instruction or on a schedule? Did a human approve it? Was the final artifact edited after approval? What uncertainty was suppressed?
Without answers, the output is difficult to trust even when it is accurate.
The authorship layer is the metadata and evidence that binds an agent-produced artifact or action to its origin, authority, and approval state.
For a consequential output, it should make the following visible or reconstructable:
Not all of this belongs in the user interface. AUX uses progressive transparency: show more reasoning and evidence while trust is being established or when stakes are high, then taper the detail without removing the underlying record.
The authorship layer supports both experience and governance. A reviewer sees enough to make a decision. An auditor can later reconstruct the full chain.
"Explainable AI" is often framed as making model reasoning understandable. That is useful but insufficient for enterprise action.
A plausible explanation does not prove that the correct data, authority, and approval process were used. Chain-of-thought-style narratives can be incomplete or misleading. The organization needs operational evidence, not only a story.
Answerability means the system can answer:
Answerability shifts trust from "the model sounded reasonable" to "the system left receipts."
The Trust Contract is the agent's operational constitution. It defines: scope and purpose; autonomy levels by action class; prohibited actions; memory and retention policy; evidence requirements; escalation triggers and service levels; user control and escape hatches; guarantees the system is expected to maintain; named trust gaps that block release or execution; and incident response and rollback posture.
At auxfirst, the Trust Contract sits across three altitudes:
The principle is more important than any specific implementation: discipline without a spec becomes a poster; a spec without runtime enforcement becomes a document; runtime controls without a coherent trust model become theatre.
It is tempting to instruct an agent to "be secure," "respect permissions," or "ask before risky actions." These instructions may influence behavior, but they are not security controls.
A probabilistic model should not be the final authority on whether it is authorized to act. The architecture around it must enforce:
The agent may propose. Deterministic policy decides whether the proposal is permitted. This is the trust harness pattern: the model reasons inside a bounded runtime that can stop, transform, route, or reject actions.
A security review captures one version of the system under one set of assumptions. Agents change more frequently than traditional applications: models are upgraded; prompts and policies evolve; tools are added; retrieval sources change; users discover new behaviors; memory accumulates; vendors alter APIs and commercial terms; workflows expand into new markets or data classes.
Trust conformance must therefore be continuous. A practical operating cadence includes:
Trust is dynamic. The operating system must be capable of retracting autonomy as well as granting it.
"The agent is weird" is not a useful incident category. Naming failure modes creates operational leverage. auxfirst's trust gap taxonomy groups failures across the four trust stages. Examples include:
A named gap can be linked to severity, owner, fix pattern, test case, and release gate. Every repeated incident should improve the system for future workflows.
A trustworthy operating loop looks like this:
This is how trust architecture compounds. The organization does not merely collect logs. It converts operational experience into better boundaries.
Quality alone cannot describe a production agent. A balanced operating view should include:
| Lens | Metrics |
|---|---|
| Quality | Accuracy and completeness · evidence correctness · consistency · task success · error and rework rate. |
| Trust | Approval rate by action class · override and correction rate · escalation appropriateness · boundary violations · unsupported confidence · user-reported trust incidents · autonomy promotion or demotion events. |
| Operational | Cycle time · queue reduction · handoff latency · runtime failure and retry rate · cost per completed workflow · percentage of actions within the intended envelope. |
| Economic | Hours returned · capacity released · revenue accelerated · loss or risk avoided · cost of controls and human review · value realized at the current autonomy level. |
The CFO should see the net operating case, not only gross time savings. An agent that saves 1,000 hours but creates 900 hours of review and remediation has not transformed the workflow.
Trust loss is not graceful. One high-heat violation can collapse confidence built through hundreds of routine successes. The recovery design should exist before the incident:
An escape hatch is not only a button in the interface. It is an organizational capability to regain control.
Trustworthy agents do not ask the model to police itself. They surround probabilistic judgment with deterministic identity, policy, evidence, escalation, and recovery.
Agent adoption is often assigned to a committee and delivered by a project team. Neither structure is sufficient for sustained operation.
A committee can align stakeholders but rarely owns the behavior of a live agent. A project team can launch a pilot but often dissolves when the system enters production. Agentic work needs durable, cross-functional ownership because the agent continues to learn, encounter exceptions, and press against its boundaries after launch.
The organizational question is not "Who owns AI?" It is "Who owns this agent, this workflow, this trust relationship, and this access lifecycle?"
The Forward Deployed Engineer, or FDE, emerged as a pattern for bringing technical builders close to the customer's real environment. In enterprise agent adoption, a similar role is needed internally.
The internal FDE is not simply an engineer embedded in a business unit. It is a translator and system builder who can move across process, data, tools, policy, and user behavior. This person or small pod works where the abstractions break:
The role is "forward deployed" because it sits inside the operating reality rather than waiting for requirements to arrive in a central AI team.
The most effective unit is usually a small pod aligned to one workflow or domain.
| Role | Primary accountability |
|---|---|
| Executive sponsor | Mandate, funding, and organizational air cover. |
| Agent product owner | Agent behavior, roadmap, outcomes, and improvement cadence. |
| Process owner | Workflow truth, exception logic, and business acceptance. |
| Internal FDE / agent architect | End-to-end operability design and technical translation. |
| Platform / engineering owner | Runtime, integrations, reliability, and deployment. |
| Security / identity owner | Identity, access, policy enforcement, and incident controls. |
| Risk / legal owner | Regulatory, contractual, and accountability requirements. |
| AUX / trust owner | Adoption, autonomy boundaries, transparency, control, and trust measurement. |
Not every organization needs eight separate people. Several roles may be held by the same person. What matters is that the accountabilities are explicit and no critical perspective is absent.
IT can build the system but cannot define the business truth alone.
When the business does not actively own the workflow, the agent automates the process as documented rather than as performed. Exceptions are discovered after launch. Business owners treat errors as technical failures even when the underlying rule was never clear. Adoption becomes someone else's problem.
The inverse also fails. A business-led agent built without identity, architecture, and security ownership becomes a shadow system with fragile credentials and no path to scale.
Agent operability is inherently cross-functional because the agent crosses functional boundaries in the act of doing work.
Many organizations have product owners, process owners, data owners, and risk owners. Few have a person accountable for whether the relationship between users and agents remains trustworthy.
The trust owner focuses on questions such as:
This role can sit within product, design, AI governance, or operations. The title matters less than the accountability.
A central AI team is useful for shared platforms, standards, vendor management, and reusable controls. It becomes a bottleneck when every workflow depends on it for local process knowledge and decisions.
A scalable model has two levels:
The centre creates the paved road. The pods make real workflows operable on it.
When automation could touch only a minority of work, IT could remain primarily an infrastructure and application function. Agents can touch almost every form of knowledge work. That expands the remit.
Technology leadership increasingly becomes responsible for the organization's delegation architecture:
This does not make IT the owner of every business decision. It makes IT the architect of the environment in which delegated decisions can occur safely.
Agent operability draws on familiar skills in new combinations:
The scarce capability is not always deep model expertise. It is the ability to see the whole operating system around the model.
For any live or planned agent, ask five people independently:
If the answers differ, the ownership model is not yet operable.
Agents need product ownership, process ownership, identity ownership, and trust ownership. A committee can advise all four; it cannot substitute for them.
Enterprise applications were designed around human users navigating interfaces. Agents prefer tools, schemas, events, and explicit contracts.
This does not mean every application must remove its interface. It means the useful capabilities of the application must be available without requiring a human to click through the interface at every step. That is the practical meaning of headless for the agentic enterprise.
A traditional enterprise application exposes: screens, forms, dashboards, menus, user roles, exports, and workflow rules hidden in configuration.
An agent-operable application also exposes:
The agent should not need to impersonate a human operating the screen unless no safer interface exists. Browser automation can be valuable as a bridge, but it is brittle, difficult to govern, and often tied to human credentials.
A vendor may say "we have an API." That does not mean the product is agent-operable.
The API may expose only a fraction of the workflow. Permissions may be all-or-nothing. Documentation may be incomplete. Write operations may not support previews or idempotency. Rate limits may make the economic case impossible. The vendor may prohibit automated use in its terms. Audit logs may attribute every call to one integration account.
Headless readiness has four dimensions.
Commercial operability is often ignored until scale. A technically elegant agent can become uneconomic if every non-human actor requires a premium seat across ten applications.
The Model Context Protocol and similar tool standards make it easier for agents to discover and call capabilities across applications. This is strategically important because it separates the agent experience from the vendor interface.
But interoperability does not remove governance. A tool description is not a permission model. A connected server can expose actions with very different heat. Clients and servers still need authorization, input validation, confirmation for sensitive operations, output validation, rate limiting, and audit logs.
The enterprise needs a tool catalogue that records:
This is the headless equivalent of an application catalogue, but oriented around verbs and authority rather than software titles.
Vendor renewal used to focus on seats, storage, service levels, integrations, and discounts. Agent operability adds a new set of questions.
These questions shift leverage. The best enterprise application is no longer only the one employees prefer to use. It is the one that can participate safely in a multi-agent operating environment without trapping context, identity, or evidence.
Review each area against evidence from the product, architecture, contract, and operating experience. Do not collapse the result into a single maturity score: one critical identity, permission, or auditability gap can set the autonomy ceiling for the workflow.
| Area | Questions to verify | Evidence of operability |
|---|---|---|
| Interfaces | Are consequential actions exposed through stable, documented interfaces rather than only the human UI? | A complete, versioned action surface with clear input, output, and error semantics. |
| Identity | Can non-human actors have distinct identities, sponsors, lifecycles, and delegated authority? | First-class agent or workload identity with attributable delegation. |
| Permissions | Can access be constrained by action, object, field, region, environment, time, and value? | A conditional, time-bound permission envelope rather than an all-or-nothing role. |
| Runtime safety | Can sensitive actions be previewed, limited, approved, retried safely, and reversed? | Dry runs, idempotency, caps, approval hooks, rollback, and policy enforcement. |
| Auditability | Can the enterprise reconstruct who or what acted, under whose authority, using which evidence and policy? | An action-level trail linking agent identity, delegated user, inputs, result, evidence, and policy decision. |
| Commercial fit | Are automated use, service identities, volume, data rights, and portability contractually clear? | Scalable agent terms, predictable economics, and exportable operational data. |
A material gap does not automatically require replacement. It shows where the workflow may need an adapter, broker, human step, contractual change, or alternative system of action.
For each stack layer, there are four legitimate decisions:
"Wait" is not failure. It is a decision to avoid funding a pilot whose constraints are already visible.
A vendor is agent-ready only when its capabilities, permissions, evidence, and commercial model can be operated without borrowing a human and hiding the real cost.
The first workflow should teach the organization how to delegate safely. It should not attempt to prove the maximum capability of AI.
The following 90-day path is intentionally practical. It gives away most of the audit methodology because the value is not in knowing that the steps exist. The value is in running them with enough rigor and cross-functional accountability to produce a defensible decision.
A strong first workflow has: meaningful volume or latency; a clear current cost; repeatable inputs and outputs; an identifiable process owner; accessible evidence of quality; mostly reversible actions; limited external exposure; a bounded data domain; an available human escalation path; and a sponsor willing to change the workflow, not only add a tool.
Good candidates include internal reconciliation, classification, compliance preparation, document intake, response drafting, quality assurance, knowledge routing, and workflow monitoring.
Weak first candidates include open-ended strategic decisions, public communications, high-value financial execution, employee discipline, legally binding commitments, and workflows whose basic rules are disputed.
Write a one-sentence outcome in business terms.
Bad: "Use an AI agent for onboarding." Better: "Reduce the median time from signed contract to implementation-ready account from five days to one, without increasing configuration or compliance errors."
Then define: current cycle time and cost; target improvement; in-scope and out-of-scope cases; the user and stakeholders; the maximum acceptable consequence of error; and the decision date for build, buy, or wait.
Name the sponsor, product owner, process owner, internal FDE or architect, engineering owner, identity/security owner, risk owner, and trust owner.
Do not proceed with "representatives will join when needed." Agent operability fails in the gaps between functions. The accountable people need to be present when boundaries are designed.
List every verb the workflow performs. Avoid capability labels. For each action record: object acted upon; current actor; system used; input and output; whether state changes; external exposure; approval or decision right; common exception; evidence left behind.
This action inventory becomes the spine of the assessment.
Phase 1 output: Delegation Case Brief + action inventory.
Process documentation and stakeholder interviews are necessary but incomplete. Review actual cases, logs, artifacts, handoffs, and exceptions.
Ask experienced operators to narrate why they made decisions, not only what they clicked. Look for: steps performed outside the system; copied data and duplicate records; unofficial source-of-truth documents; workarounds used near deadlines; exception categories that are not written down; approvals obtained in chat or email; handoffs that depend on personal relationships; moments where the operator pauses because "something feels wrong."
The difference between the first two is process debt. The uncertainty in the third is the operability work.
The exception surface is the set of conditions under which the routine process stops being routine. Capture: exception type; frequency; consequence; current resolver; evidence used; whether a policy exists; whether similar cases are decided consistently; required escalation time.
A workflow with a small, well-understood exception surface is a better first candidate than one where every case is "special."
Phase 2 output: Verified current-state map + exception register.
Data shape assessment. For every action, map required context and its authority. Classify sources across D0–D4. Identify the minimum shaping work needed for the target autonomy. Do not create a general data-cleanup backlog. Tie each issue to an action and consequence.
Process design assessment. Place every action into read, draft, decide, or execute. Score the five heat dimensions. Assign the default control posture. Identify de-escalators that reduce heat without destroying value.
Trust & permissions assessment. Draft the Agent Identity Card and permission envelope. Identify whether the agent acts as itself or on behalf of a user. Name sponsors, owners, escalation recipients, memory rules, and authorship requirements.
The target autonomy is capped by the weakest layer. For each action, record: desired autonomy; current safe autonomy; limiting layer; required fix; owner and effort; evidence needed to promote autonomy later.
Phase 3 output: Agent Operability Map + gap register.
Redraw the workflow as a human–agent operating model. The target design should show: triggers and workflow states; agent, human, and system actors; data and context objects; actions and heat bands; approval and escalation points; tool calls and permission scopes; retry, dead-end, and rollback paths; authorship and audit artifacts; success, trust, and economic metrics.
Define: what the agent guarantees; what it may do automatically; what requires confirmation or named approval; what is forbidden; what uncertainty triggers escalation; what it remembers; what evidence it must leave; how it is paused and recovered; what incidents block operation.
Ask: what is the smallest form of delegation that creates a meaningful business result?
For an onboarding workflow, that might be: agent reads the contract and customer record; agent creates a complete onboarding pack; agent drafts system updates and missing-information requests; human approves customer-facing communication and non-standard configuration; agent executes approved internal updates; agent monitors completion and escalates delay.
This may deliver most of the cycle-time value without requiring autonomous external communication or financial commitment.
Phase 4 output: Agent-ready workflow + Trust Contract + Agent Identity Card.
Run the workflow against real historical cases and designed edge cases. Test: routine success; missing and conflicting context; stale policy; unauthorized data request; high-value or bulk action; ambiguous user intent; unavailable system; duplicate trigger; prompt injection or untrusted instruction in retrieved content; incorrect but plausible recommendation; escalation recipient unavailable; partial failure after one state change; sponsor or approver change.
The objective is not to demonstrate that the model can handle everything. It is to verify that the operating model fails safely and visibly.
Build if the workflow is differentiated, the stack is adequate, and the remaining gaps are tractable. Buy if a vendor meets the identity, permission, evidence, and commercial requirements. Orchestrate if the value lies in connecting existing tools under a shared trust layer. Wait if the critical layer would require disproportionate transformation or the economic case depends on unsafe autonomy.
Phase 5 output: Evidence-backed recommendation + scoped implementation path.
Build only the slice required to test the delegation case. The implementation should include from day one: distinct identity; narrow tools and data scopes; structured context manifest; action limits and approval gates; runtime state and retries; authorship metadata; audit logging; pause and rollback controls; evaluation cases; and an operational dashboard for the owner.
Do not postpone these as "production hardening." They are the product.
Create a representative set of cases with expected outcomes, acceptable variants, prohibited actions, and escalation expectations. Golden cases should cover: common routine work; each exception category; each high-heat action; known failure modes; and cases where the correct outcome is to ask, refuse, or escalate.
A system that only evaluates completed outputs will miss whether the agent should have stopped.
Phase 6 output: Controlled working slice + evaluation harness.
Launch with a defined supervision model rather than an informal "human in the loop." Specify: which actions are reviewed every time; which are sampled and at what rate; who reviews and within what SLA; how corrections are recorded; how autonomy is paused; how incidents are classified; what evidence is required for promotion; what performance would trigger a wait or redesign decision.
Measure the whole operating model.
| Dimension | Example measure |
|---|---|
| Business | Cycle time, throughput, backlog, revenue or risk impact |
| Quality | Accuracy, completeness, rework, error severity |
| Trust | Approval, override, escalation, boundary violations |
| Operational | Runtime failures, retries, human review time |
| Economic | Net hours returned, cost per case, payback period |
| Adoption | Active use, abandonment, repeated delegation |
A successful first workflow does not need to be autonomous. It needs to produce a better operating result with a control model the organization is willing to repeat.
At day 90, the organization should be able to answer:
The result is not merely one pilot. It is the first reusable piece of the organization's delegation architecture.
The first 90 days should prove an operating model, not a demo. Pick one workflow, cool the actions, make authority explicit, and leave behind reusable infrastructure.
The first agent-operable workflow is expensive because the organization is building more than an agent.
It is learning how to map reality rather than documentation. It is shaping context and authority. It is defining action heat. It is creating a distinct identity and permission envelope. It is deciding what authorship means when software contributes to work. It is building escalation, evidence, monitoring, and recovery. It is naming owners who previously sat in separate functions.
Done well, that work is not repeated from zero. The second workflow can reuse:
This is why operability compounds.
Every captured failure becomes a permanent edge if it is turned into a named gap, policy rule, test case, de-escalator, or design pattern. Every successful delegation case gives the organization evidence for where autonomy can expand. Every workflow improves the paved road for the next one.
The durable advantage will not come from exclusive access to the smartest model. Capable models are increasingly available to everyone. The advantage will come from the organization's ability to turn its context, decisions, systems, and trust relationships into a governed environment that agents can operate.
The enterprise that wins is not the one with the most agents. It is the one that can answer, for every consequential action:
Models make agents capable. Operability makes them useful. Trust makes them adoptable.
Use this checklist for one workflow, not for the enterprise as a whole.
Score each statement: 0 — not true · 1 — partly true / informal · 2 — mostly true / documented · 3 — consistently true / enforced and evidenced
Do not rely only on the total score. Calculate each layer as a percentage — the lowest layer is the operability ceiling. A workflow scoring 90 overall but only 45% in trust & permissions is not production-operable for high-heat action.
The consequence carried by an agent action if it goes wrong, assessed across reversibility, blast radius, exposure, commitment, and authority.
auxfirst's framework for mapping action heat to a control posture: auto-run, sampled review, propose + approve, named approver, or human execution.
A one-page, human-readable definition of an agent's purpose, sponsor, owners, scope, data, tools, actions, permission envelope, trust stage, escalation, memory, authorship, and review lifecycle.
The capacity of a specific workflow to be performed by an agent with bounded autonomy, usable context, explicit decision rights, and reconstructable accountability.
An organization that can repeatedly convert workflows into governed delegation cases using shared identity, permission, context, process, trust, and evidence infrastructure.
The ability of the system and organization to explain and evidence what the agent attempted, was allowed to do, used as context, changed, escalated, and left behind — with named accountability.
The metadata and evidence binding an agent-produced artifact or action to agent identity, initiating user or event, model and policy version, sources, approvals, final executor, and audit record.
The amount of independent action an agent has demonstrably earned for a workflow. Autonomy beyond evidence is assumed trust and increases the risk surface.
The practice of giving an agent the minimum sufficient, authoritative, task-specific context rather than the maximum available context.
A record of the sources, versions, scopes, and exclusions supplied to an agent for a particular workflow run or decision.
The degree to which information is findable, authoritative, structured, semantically clear, scoped, fresh, and linked to permissible action.
Governed traces of prior human decisions — situation, evidence, rationale, owner, scope, and validity — retained as context without treating historical precedent as universal policy.
The shared enterprise infrastructure and rules for assigning work and authority to non-human actors: identity, context, tools, permissions, policy, evidence, monitoring, and human accountability.
A defined business case specifying the workflow, actions delegated, required context, authority, controls, handoffs, evidence, accountability, and expected economic result.
A design move that cools an action: draft-only output, sandboxing, undo windows, hard caps, sampled review, or narrow allowlists.
The conditions under which a routine workflow becomes non-routine, including the frequency, consequence, resolver, evidence, and escalation needs of each exception.
Confidence that the agent can complete basic tasks reliably and predictably.
Confidence that the agent understands relevant history, preferences, scope, and situational context.
Confidence that the agent can make appropriate calls under ambiguity, including asking, refusing, and escalating.
Confidence that the agent will act in the user's or organization's intended interest when incentives, metrics, or objectives conflict.
Context whose authority, freshness, scope, provenance, retention, and permissible use are continuously defined and enforced.
The capacity of an enterprise application to expose useful states and actions through secure, documented, machine-operable interfaces with appropriate identity, permission, audit, and commercial support.
A workflow design that assigns each action, decision, approval, escalation, and accountability to the appropriate human, agent, or deterministic system component.
The lowest level of agent delegation that creates a meaningful business result. It is the preferred starting target for an operability design.
The maximum safe autonomy supported by the weakest of the three layers: data shape, process design, and trust & permissions.
The accumulated hidden work created when agents rely on ambiguous data, undocumented process logic, borrowed credentials, manual approvals, or incomplete evidence rather than durable operating infrastructure.
The bounded combination of resources, actions, conditions, limits, autonomy posture, duration, delegation chain, escalation, and evidence requirements under which an agent may operate.
A bounded, governed machine for one business process, built from a source of truth, named skills, policies, context, and outputs that can be run consistently rather than recreated through ad hoc prompting. More at auxfirst →
The AUX principle of showing more reasoning, evidence, and control while trust is being established or stakes are high, then tapering visible detail while preserving the underlying record.
The design of identity, boundaries, evidence, control, escalation, authorship, monitoring, and recovery that makes agent action trustworthy and answerable. More at auxfirst →
The agent's operational constitution: scope, autonomy by action class, prohibitions, memory, evidence, escalation, guarantees, trust gaps, and incident posture.
The runtime enforcement layer around an agent that applies deterministic policies, permission gates, escalation triggers, telemetry, and audit rules to probabilistic proposals and actions. More at auxfirst →
An event where agent behavior violates or materially pressures the intended contract, boundary, evidence requirement, or user relationship — even if no traditional security breach occurs.
The person accountable for autonomy boundaries, transparency, control, escalation, adoption, and the ongoing health of the human–agent relationship.
This field guide is an auxfirst framework informed by the following external standards, technical documentation, and enterprise observations.
auxfirst is the agency built for the agentic era. We help enterprise leaders, product teams, and developers design agents that remember context, adapt over time, and earn the right to act. Our work connects Agentic Experience Design, process architecture, identity, permissions, trust contracts, and runtime controls — so AI moves from a capable demo into a governed operating model.
The Agent Operability Audit answers that question for one real workflow — in three weeks, at a fixed price.
auxfirst maps the workflow as it actually runs and audits the three layers: data shape (what the agent can consume, what remains trapped in tribal knowledge, and what must be shaped before action), process design (what the agent should read, draft, decide, and execute, using the Action Heat Ladder to set the right control posture), and trust & permissions (the agent identity, trust stage, permission envelope, authorship layer, escalation paths, and audit requirements).
This is not a data cleanup project, an AI strategy deck, or a pilot. It is the diagnostic that tells you whether the pilot will survive contact with your operating model — before you fund it.