Agentic Integration Patterns

Agentic integration gives a model some discretion over the sequence of tools used to complete a task. That discretion can be useful when the next evidence source depends on what the previous source reveals. It should not grant the model discretion over application permissions, approval requirements or the meaning of a completed business action.

The integration architect must decide where dynamic investigation ends and controlled execution begins. This guide focuses on that boundary: tool contracts, delegated identity, proposal state, approval binding and recovery. It is a practical part of AI integration and delivery, rather than a general argument that every workflow needs an autonomous agent.

Choose the minimum useful planning freedom

Anthropic's research on effective agents distinguishes predefined workflows from systems in which models dynamically choose steps and tools. Use that distinction to identify the actual source of value. If the next step is already known from a field or rule, an ordinary workflow may be simpler to test and operate.

Dynamic planning helps when an investigation can branch legitimately. An asset-location discrepancy might require a recent scan, a checkout record or a site transfer reference depending on the first evidence found. The agent can choose the next permitted read, but the application still decides which records it may access and whether a proposed correction is valid.

Integration patterns by planning and execution boundary

Pattern	Model discretion	Control retained in code
Routed workflow	Classify the request into a permitted route	Allowed routes, required fields and subsequent steps
Agent inside a bounded task	Select permitted evidence reads	Scope, budget, stop rules and output validation
Planner with controlled executor	Propose a sequence of operations	Operation allow-list, current permission and state preconditions
Review-and-submit workflow	Prepare an evidence-linked proposal	Approval identity, exact approved content and authorised submission
Specialist agent collaboration	Divide analysis among defined specialists	Shared authority boundary, evidence provenance and final action ownership

These are design options, not maturity levels. More agents do not automatically produce a stronger integration. A single bounded investigator may satisfy the task with fewer state transitions, fewer failure paths and a clearer owner.

A worked boundary: investigate an asset-location mismatch

The example is illustrative. A maintenance organisation finds that asset LF-17 is listed at Site A while a recent authorised scan suggests Site B. The agent may gather evidence and prepare a location-review case. It cannot move the asset, change its safety status or overwrite the authoritative location register.

Give the runtime a verified task context: requesting identity, permitted sites, asset identifier, purpose, deadline and available read capabilities. Do not let the agent expand site access because a document mentions another site. If the discrepancy requires evidence outside the requester scope, the correct result is a documented access limitation and escalation.

Illustrative narrow tool contracts

Tool	Permitted purpose	Required constraint
Read asset record	Retrieve current identity, location and revision	Authorised asset and permitted fields only
Read checkout history	Find relevant checkout and return references	Bounded period and verified site scope
Read scan evidence	Retrieve relevant location observations	Source timestamps and scanner provenance preserved
Prepare review proposal	Store evidence and a proposed disposition	No authoritative location change
Submit approved review case	Send the approved case to the designated queue	Current permission, bound approval and stable operation identity

Prefer these narrow capabilities to a general “query database” or “call any endpoint” tool. A tool description helps the model select a capability; enforcement belongs in the tool service. The API contract should define the operation independently of the prose used to describe it to the model.

Define tool-result semantics as carefully as tool inputs. A partial history, truncated response or unavailable source should carry an explicit state that the agent cannot mistake for complete evidence. Preserve units, timestamps and record versions. The runtime should reject malformed tool results or route them for investigation, rather than letting the model infer that an empty response means no relevant activity occurred.

Carry identity through delegation

An agent often executes through a service identity, but the business request still has an originating user or process. Define whether the service acts on behalf of that user or under a separately approved service scope. Do not mix the two accidentally, such as retrieving with an administrator account and assuming the user may see every returned field.

Each tool call should receive trusted context from the runtime, not accept authority from model-generated arguments. Validate the requested resource and operation at execution time. The access-control design should cover delegation, service identities and the consequences of access being revoked during a long-running task.

When several agents collaborate, they do not gain independent permission merely by having different role names. A specialist can analyse a limited evidence set without receiving the full tool catalogue. Record which evidence each specialist used and which component remains responsible for any eventual application action.

Bind approval to the proposal that was actually reviewed

For LF-17, the investigator might propose “open a location reconciliation case” with three source references and an unresolved checkout discrepancy. Store that proposal as a versioned object. The reviewer sees the evidence and approves the exact proposal version, destination and permitted action.

Before submission, check that the proposal has not changed, the approval is still valid, the reviewer had the required authority and relevant source or target state remains compatible. If the agent adds another asset or changes the destination after approval, the prior approval should not silently authorise the new content.

An approval button is not sufficient if it authorises an open-ended future plan. Prefer bounded approval meaning: this version of this proposal may be submitted to this queue under these preconditions. Whether every action requires human approval depends on the actual risk and operating policy; whatever rule is chosen must be enforced outside the model.

Persist state outside the conversation

A conversation transcript is useful evidence but a weak substitute for workflow state. Store the task identity, evidence references, completed reads, proposal version, approval decision and submission outcome in a durable application model. A restarted worker should know whether it is investigating, awaiting review or reconciling an already attempted submission.

Do not infer completion from the agent saying “done”. Completion requires the receiving application evidence defined in the contract. If submission times out, the task enters an unknown-outcome state until it is reconciled. Replaying the entire conversation can repeat unnecessary reads and, without safeguards, repeat actions.

Separate analysis retries from action retries. Re-running a read-only interpretation may be acceptable within a cost budget. Reissuing an external operation requires its own identity and outcome rules. Use event-driven integration where durable events support state changes, while preserving the distinction between a proposed action and an accepted fact.

Constrain loops, cost and untrusted instructions

Set limits on tool calls, repeated requests, elapsed time, retrieved volume and total spend where measurable. A stop condition should produce a useful partial result: evidence obtained, unresolved question and next owner. It should not simply disappear after the runtime exhausts a token budget.

Detect repeated actions that add no new evidence. If the asset register and scan store keep returning the same contradiction, another identical query is unlikely to resolve it. Escalate the discrepancy rather than encouraging the agent to keep trying until it invents a confident answer.

OWASP's prompt-injection guidance explains how external content can influence model behaviour. In this design, a checkout note telling the agent to change tools or reveal another site is untrusted content. Guardrails should protect the surrounding boundaries even when the model follows an unwanted instruction.

Evaluate the integration as a sequence of decisions

Test whether the agent chooses relevant permitted evidence, recognises missing authority, stops within limits and produces a reviewable proposal. Then test the deterministic executor separately: stale proposal, revoked access, changed target state, invalid approval and duplicate submission. A high-quality final paragraph does not compensate for an unauthorised intermediate read.

For the asset case, include a stale scan, two assets with similar labels, a checkout record outside the permitted site, a scan with uncertain provenance and a contradictory source note. The expected outcome may be an unresolved case rather than a location recommendation. Grade the disposition as well as the language.

Record observable decisions and tool evidence rather than demanding hidden model reasoning. The audit question is which information and authority supported the action, not whether a generated explanation sounds persuasive. Use audit logging to reconstruct the task without routinely exposing sensitive source content.

Keep the retained operating responsibility explicit

Assign owners for tool definitions, permission policy, prompt releases, exception queues and source-system changes. A tool can remain reachable while its business meaning changes, so evaluate changes to fields, defaults and destination state. Decide who can suspend the agent and how pending work is handled during a suspension.

Trusted Data's Saudi enterprise GenAI guide provides related commercial reading on implementation. The integration decision here remains specific: which investigation choices improve the task, and which authority boundaries must remain deterministic?

Discuss a bounded agentic integration with the allowed tools, a representative investigation, the exact action boundary and the evidence required before the receiving system accepts a result.