The agent inherits the workflow

An enterprise agent is often introduced as a new worker with a specific job. Resolve billing questions. Support an insurance claim. Handle an internal service request. The description sounds bounded because the verb is bounded. The real workflow contains policy exceptions, stale records, missing approvals, overloaded queues, regional differences, informal workarounds, and cases that experienced staff know not to treat as ordinary. The agent inherits all of them the moment it begins to act.

OpenAI's July 22 description of Presence starts deployments with a specific job, limited knowledge and system access, company policies, approved actions, and rules for when a person should take over. That is the right operating frame. It also reveals the size of the work hidden behind the phrase deploy an agent: the workflow must be made explicit enough to test, enforce, observe, and change.

A model cannot repair a contradictory operating environment by reasoning harder. If the knowledge base says one thing, the billing system encodes another, and experienced staff follow a third practice, the agent will choose among institutional disagreements it did not create. Its output may look like model behavior while actually exposing process debt.

Map the work before the model

Workflow discovery should follow representative cases from arrival to durable resolution. Which systems provide facts? Which policy version applies? Where can staff exercise discretion? Which cases are transferred, appealed, reopened, or corrected? What downstream effect closes the work? The map should include failures and exceptions, not only the path used in a product demonstration.

This changes evaluation design. A correct answer in a simulated conversation is insufficient when the real job involves identity verification, account state, tool calls, approval, and follow-up. The test must ask whether the complete route produced the right consequence under the right authority and whether the record is adequate when the customer contests it.

The agent does not automate the written procedure; it automates the institution that actually executes it.

Deployment teams should separate defects by source. Some failures come from the model. Others come from missing data, incompatible policies, broken integrations, unstaffed escalations, or goals that reward premature closure. This classification prevents a new prompt from becoming the universal patch for problems that belong to operations.

The workflow will continue changing after launch. Products change, customer behavior shifts, regulations move, staff learn new exceptions, and upstream systems are replaced. The agent therefore needs a governed way to inherit changes: versioned policies, controlled tests, staged rollout, and a record of which workflow definition governed each consequential interaction.

Start the map with work that resists standardization. Review the cases senior staff remember, the requests that bounce between teams, the adjustments that require a supervisor, and the outcomes customers successfully appealed. These examples reveal the unwritten hierarchy of rules: which source wins during disagreement, when service recovery can override a default, and which ambiguity must remain with a person. An agent trained only on routine completions will encounter that hierarchy for the first time in production.

The surrounding incentives belong in the model of the workflow. A contact center measured on handle time, a claims team measured on leakage, and a customer-success team measured on retention may interpret the same case differently. Giving an agent a single objective does not remove those tensions. It can merely choose one invisibly. Evaluation should expose the tradeoff and require the accountable business owner to decide which consequence is acceptable.

After launch, compare agent-handled cases with the broader population, not only the cases the agent completed. Transfers, timeouts, abandoned sessions, reopened work, manual corrections, and downstream complaints are part of the denominator. Otherwise difficult cases can disappear from the performance claim precisely because the automation failed to finish them. The workflow is the unit of accountability, so its measurement boundary must be wider than the agent session.

Name the conditions that prevent automation before setting a target rate. Missing identity evidence, contested authority, conflicting records, or unavailable appeals may justify stopping regardless of model confidence. These are workflow admission rules, not failures to be optimized away. Publishing them gives frontline teams a stable reason for intervention and keeps completion metrics from turning known institutional gaps into pressure for unsupported action.

Operate the boundary

The practical starting point is a named control for the end-to-end workflow definition. Write the boundary in terms an operator can evaluate: the initiating principal, permitted purpose, affected resources, allowed consequences, escalation path, expiry condition, and evidence produced. A policy sentence is useful context; the enforced object and its observable state are what make the policy operational.

Test the boundary by running ordinary, exceptional, disputed, and reopened cases through every system and human handoff that can change the outcome. Preserve the starting state, the agent's route, any intervention, the final effect, and the gaps in observation. Repeat the exercise after changing a model, tool, provider, policy, or data source. A control that passed once should not silently lend its assurance to a materially different system.

The leading signal is the share of failures attributable to workflow ambiguity, missing ownership, or inconsistent system state rather than model output alone. Pair it with a consequence measure so teams do not optimize the dashboard while weakening the outcome. Review both on a fixed cadence and after every material incident or migration. When the signal disappears, determine whether the risk disappeared or the instrumentation did.

The business-process owner, not the model team alone, should own the decision to continue, narrow, pause, or expand the workflow. The owner needs authority over the control and access to its evidence; responsibility without either becomes ceremonial. Record the decision, the evidence cutoff, the residual uncertainty, and the next review date so the claim can age honestly.

— Dispatches · Summit Cognitive