Map the Work Before You Build the Agent

Take an illustrative customer renewal. The CRM says the opportunity is on track. The support platform shows an unresolved severity-one incident. A call transcript includes a commitment to provide a migration plan. Finance has reduced the discount authority of the account team, but the old limit still appears in a sales playbook.

An agent cannot resolve this by learning the generic steps of “renew a customer.” It needs a map of this organization’s records, events, decisions, and authority. Building that map after the agent has failed usually means the team started with instructions instead of the work.

Begin at the finish line

The first artifact should define the completed outcome in observable terms. For this renewal, that might be an approved brief, assigned mitigation actions, a documented commercial position, and specific CRM fields updated with source-linked evidence.

That outcome sets the boundary of the map. It prevents the design from expanding into every system or conversation related to the customer. It also exposes the decisions that require human ownership: accepting contractual risk, approving a concession, or making a commitment to the customer.

The published customer renewal workflow provides one bounded example. It separates account facts from inference, preserves commercial authority, and treats updates as field-specific actions rather than one broad permission to “manage Salesforce.”

Map four different kinds of object

A workflow map becomes useful when it distinguishes objects that behave differently.

Entities are durable nouns: customer, contract, product, incident, account owner, approval policy.

State describes what a system currently records: renewal date, incident severity, contract status, owner, approval limit.

Events explain change: a ticket escalated, a commitment was made, an amendment was approved, an owner changed.

Authority determines who or what may make the next decision: the finance approver, the contract owner, the incident commander, or a policy rule.

Combining these into one undifferentiated knowledge store creates ambiguity. A meeting note may mention a discount but does not become the authoritative discount policy. An event can explain why a field is stale without becoming permission to overwrite it.

Observed work and inferred process need different treatment

A context graph can connect enterprise entities with temporal traces of actions and events. Those traces help explain how a renewal reached its current state, including which actions came from people, which came from agents, and which decision remains unresolved.

That approach surfaces an important implementation risk: a frequent path is not necessarily a correct path.

Employees may repeatedly bypass a slow approval step. A high-performing account team may rely on an informal spreadsheet that is not governed. Two similar sequences may belong to different products or regions. A new workflow may be correct but lack enough history to rank highly.

The map should therefore label what is directly observed, what is inferred, and what has been approved as the intended operating path. Inference can propose a relationship or likely next step. It should not silently establish policy.

Let exceptions shape the design

The happy path rarely reveals the context an agent will actually need. Exceptions do.

For the renewal example, test the map against cases such as:

• the contract and CRM disagree on the renewal date;
• the support incident is restricted to a small response team;
• the account owner changed yesterday;
• the customer commitment has no named owner;
• two discount policies appear current; or
• the CRM update succeeds but the task creation call times out.

Each exception forces a design decision. Which source wins? What may the agent disclose? Can it retry safely? Who receives the escalation? What evidence must the handoff contain?

A workflow map is a maintained artifact

The business will change after deployment. Systems are replaced, owners move, and policies gain exceptions. A static process diagram will drift unless agent runs can expose mismatches between the map and the work.

The operating team should review recurring escalations, failed source lookups, rejected recommendations, and manual corrections. Those signals can update source authority, tool behavior, or the workflow boundary. They should not automatically rewrite the approved process.

Coryntas AI Agents are designed around this managed lifecycle: define the outcome, assemble context, establish controls, evaluate the complete path, and improve it through controlled change.

Mapping the work does not eliminate uncertainty. It makes uncertainty visible early enough to decide where the agent can act, where it must ask, and where a person remains responsible.