Agentic workflows in production need an operating contract for every action.

An agentic workflow combines software-defined steps with model-driven decisions and tools. A fixed workflow follows a designed sequence. An agent can select its next step within an assigned objective and available tools. Production designs can use both: deterministic validation and authorization around bounded model judgment.

Anthropic's engineering guide distinguishes predefined workflows from agents that dynamically direct their processes. That distinction helps locate the control boundary. A model may choose a candidate action; the system still needs to establish whether that actor may perform that action on that object now.

Begin with the simplest design that can complete the workflow. A reliable classification step followed by a human decision may be enough. Add dynamic planning when the task requires it, and preserve a way to observe the decisions and contain failure. More tool calls create more interactions to understand, test, and operate.

For each action, record the triggering event, accountable owner, permitted actor, target object, input schema, source requirements, approval rule, and expected result. Include version identifiers and the evidence needed to determine whether the action completed. The downloadable template is a design aid; implementing its controls remains an engineering task.

Treat retrieved text, documents, and tool output as data. They can inform a proposal, but they cannot grant new permissions. Authorization should come from the application's established identity and policy controls, applied to the current object and operation. Validate the action again at execution if approval and execution occur at different times.

Tie approval to the exact proposal and the approved scope. If a material field, target, version, or permission changes, the previous approval may no longer apply. Define that invalidation rule explicitly instead of relying on a message saying that someone approved the work earlier.

1. Intent: the outcome and exact external effect being requested.
2. Authority: actor, tenant or workspace, object, permission, and approving role.
3. Context: authoritative sources, versions, freshness, and uncertainty handling.
4. Execution: validated inputs, duplicate protection, timeout behavior, and completion evidence.
5. Recovery: stop condition, reconciliation owner, compensating action, and retained record.

Use a synthetic service ticket. The agent reads an approved procedure and proposes changing the ticket's category. A reviewer approves the exact ticket and category. The application validates current access, sends the update with a stable action identifier, and records the destination's receipt. No real customer data is required to exercise this design.

Now interrupt the connection after the destination accepts the update. The absence of a response does not establish that nothing happened. The recovery path checks the action identifier or reconciles against the destination before deciding whether to retry. A changed ticket category represents a new intent and needs its own decision, not reuse of an old approval.

The Builders' Library describes caller-provided request identifiers as a way to express intent and recognize retries. That pattern is useful where the destination supports it. If it does not, document the remaining uncertainty and give an operator a reconciliation path. A local identifier alone cannot guarantee that a remote side effect happened exactly once.

A workflow evaluation needs separate observations for answer quality and action correctness. A plausible explanation can accompany an unauthorized change. A correct proposed change can still fail during integration. Record both so the system's language quality does not obscure execution behavior.

Create representative successful cases, then exercise stale context, conflicting sources, unexpected tool output, denied access, expired approval, repeated requests, interrupted responses, and changed inputs. Include a document that tries to issue instructions to the agent. Verify the resulting behavior at the application boundary and retain the affected version and trace.

Make release criteria specific to the consequence. The operating owner chooses the relevant thresholds and review process. Repeat consequential cases when model variability matters, inspect results by failure category, and keep a receiving-team exercise in the acceptance plan. This links evaluation to a decision the business can actually make.

The AI software development lifecycle, or AI SDLC, should carry the workflow's operating assumptions from design into code review, tests, release, and support. Keep the contract version with the implementation. Changes to model configuration, source access, tool interfaces, or approval rules should identify which acceptance conditions need to be checked again.

Agentic coding can help create and inspect these artifacts. The engineering team still owns the requirements, repository boundaries, review decisions, and release authority. A useful coding-agent task names the files or subsystem in scope, expected behavior, relevant checks, and the evidence the reviewer needs.

For a first implementation, take one action that currently crosses from a recommendation into an external system. Complete the contract, build the success path, and force an uncertain-result scenario before expanding autonomy. LockedIn Labs uses the same workflow-first questions when scoping AI implementation and forward-deployed engineering engagements.