Skip to content
Agentic Engineering Fieldbook

Cross-Domain Pattern Synthesis

The previous cases show different domains: code, research, support, data analysis, and business operations. Their artifacts differ. A patch is not a research memo. A refund is not a SQL query. A support escalation is not a code review. Yet the same engineering shapes recur.

This chapter promotes only patterns that appear across more than one domain. A pattern here is not a prompt recipe, persona, vendor template, or maturity slogan. It is a reusable package: problem, context, solution, trade-off, and failure boundary.

Thesis

Section titled “Thesis”

The durable patterns in agentic systems are control structures: scoped workspaces, evidence-backed context contracts, authority envelopes, verification loops, reviewable transition proposals, escalation defaults, durable state, and post-run learning. They transfer across domains only when their assumptions transfer.

Cross-domain synthesis is useful because it lets teams recognize repeating problems. It is dangerous when it erases the domain-specific evidence that made a pattern safe.

Pattern 1: Scoped workspace

Section titled “Pattern 1: Scoped workspace”

Problem. The agent needs continuity across steps, but raw chat history is not enough to preserve truth, ownership, artifacts, permissions, and progress.

Context. Appears in coding workspaces, research projects, support cases, analysis notebooks, and business-process cases.

Solution. Give the agent a workspace with a durable goal, state, artifacts, participants, permissions, activity records, and terminal state. The workspace should distinguish source records from derived summaries.

Trade-off. Workspaces add product and data-model complexity. They are worth it when work spans multiple steps, tools, participants, or sessions.

Failure boundary. A workspace is unsafe when it becomes an ungoverned memory pile. Old assumptions, expired permissions, and stale summaries must not silently govern new actions.

Pattern 2: Evidence-backed context contract

Section titled “Pattern 2: Evidence-backed context contract”

Problem. Agents fail when they receive too little context, the wrong context, stale context, or context whose authority is unclear.

Context. Repository files, source citations, support policies, schemas, metrics, and process records all need context boundaries.

Solution. Define the required, optional, and excluded information for the next material decision. Record source type, date, version, owner, and limitations when they affect the outcome.

Trade-off. Context contracts slow initial design, but they reduce hidden assumptions and make evaluation more meaningful.

Failure boundary. A context contract does not make its sources true. It only makes the inputs inspectable and bounded.

Pattern 3: Authority envelope

Section titled “Pattern 3: Authority envelope”

Problem. Model capability can be mistaken for system permission. If a model can describe an action, the system may accidentally let it perform that action.

Context. Code edits, customer account changes, data exports, process approvals, and external messages all require action boundaries.

Solution. Define an authority envelope: resources the agent can see, tools it can call, actions it can recommend, actions it can stage, actions it can commit, approvals required, budgets, and stopping rules. Enforce the envelope outside prompts.

Trade-off. Narrow authority can reduce convenience. Broad authority increases the blast radius of mistakes, prompt injection, and confused-deputy failures.

Failure boundary. The envelope fails if downstream tools use broader credentials than the user or task should have, or if approvals are vague and reusable.

Pattern 4: Verification loop

Section titled “Pattern 4: Verification loop”

Problem. An agent’s self-report is not enough to prove task success.

Context. Coding agents run tests, research agents check citations, support agents verify case resolution, data agents rerun code, and process agents reconcile external effects.

Solution. Couple each delegated loop to observable success criteria. Capture attempts, tool outputs, failures, retries, and final evidence. Evaluate outcomes and traces, not only final text.

Trade-off. Verification costs time and infrastructure. It also reveals that some attractive tasks are not yet fit for autonomy.

Failure boundary. Verification can become theater when the agent chooses weak tests, cites irrelevant sources, validates only happy paths, or optimizes to visible checks.

Anthropic’s agent-evaluation article and OpenAI’s evaluation playbook both support treating the harness, tools, budget, prompts, and environment as part of the evaluated system (Anthropic, 2026; OpenAI, 2026).

Pattern 5: Reviewable transition proposal

Section titled “Pattern 5: Reviewable transition proposal”

Problem. Consequential work often requires the agent to move from analysis to action. If that move is implicit, reviewers cannot tell what is being authorized.

Context. Pull requests, refunds, SQL exports, procurement approvals, customer messages, and case state changes.

Solution. Before committing a consequential effect, represent the next step as a transition proposal: target, operation, actor, authority, inputs, evidence, expected effect, reversibility, and expiry. Accept, reject, revise, or escalate the proposal through deterministic controls or responsible actors.

Trade-off. Proposal workflows add friction. They are unnecessary for low-risk read-only answers, but essential when external effects, money, privacy, access, or public commitments are involved.

Failure boundary. A proposal is not safe if it hides material evidence, bundles unrelated actions, or remains valid after the underlying state changes.

Pattern 6: Escalation default

Section titled “Pattern 6: Escalation default”

Problem. Agents are often optimized to continue, but responsible systems need a safe way to stop, ask, or transfer ownership.

Context. Ambiguous coding tasks, unsupported research claims, angry support customers, anomalous data, and business exceptions.

Solution. Define escalation triggers before runtime. Include missing evidence, repeated failure, high-risk action, policy conflict, identity uncertainty, unsafe tool output, and user dispute. The handoff should include usable state and evidence.

Trade-off. Escalation reduces automation rate. It improves safety, recoverability, and user trust when the agent leaves its competence or authority.

Failure boundary. Escalation fails when nobody owns the queue, the receiving actor lacks evidence, or the user experience treats escalation as abandonment.

Pattern 7: Durable state and recovery

Section titled “Pattern 7: Durable state and recovery”

Problem. Multi-step agents can lose track of accepted progress, external effects, approvals, and obligations across interruptions.

Context. Long coding tasks, research projects, support cases, analysis artifacts, and business processes.

Solution. Persist authoritative state outside the model. Record checkpoints, accepted transitions, external effects, unknown outcomes, compensations, owners, and terminal states. Use summaries as derived views, not sources of truth.

Trade-off. Durable state requires schema and lifecycle design. Without it, long-running agents become hard to resume, audit, or retire.

Failure boundary. Durable execution machinery does not guarantee business correctness. The stored state must be tied to domain meaning and execution boundaries.

Pattern 8: Post-run learning

Section titled “Pattern 8: Post-run learning”

Problem. Agent systems drift as models, prompts, tools, data, users, and environments change. One successful run does not establish future reliability.

Context. Failed tests, bad citations, support reopens, data corrections, process incidents, and user interventions.

Solution. Feed reviewed failures and corrections into maintained evaluation suites, context sources, policies, playbooks, and release gates. Keep raw incidents separate from approved reusable knowledge.

Trade-off. Learning loops require ownership and curation. Automatically absorbing every correction can create new errors, privacy leaks, or policy drift.

Failure boundary. Post-run learning fails when telemetry becomes unreviewed memory, or when teams optimize only for metrics that are easiest to capture.

How patterns transfer

Section titled “How patterns transfer”

Patterns transfer by analogy, not by copy-paste. Before using a pattern in a new domain, ask:

  • What is the accepted outcome?
  • What evidence proves progress?
  • What external effects are possible?
  • Who owns the decision?
  • What data and permissions are involved?
  • What failures are reversible?
  • What must be escalated?
  • Which prior domain is most similar, and where does the analogy break?

For example, a code-review pattern can inform data-analysis review because both need inspectable artifacts and executable checks. But code tests and SQL validation are not interchangeable. A support escalation pattern can inform business-process exception handling because both transfer ownership, but customer-facing empathy and contractual obligations may change the product requirement.

What not to promote

Section titled “What not to promote”

Several attractive ideas should not become cross-domain patterns:

  • Agent persona as architecture. Role prompts can help style and task framing, but they do not define authority, verification, or state.
  • One universal tool loop. Domains differ in evidence, latency, privacy, and reversibility.
  • Confidence score as trust. Confidence is only meaningful when calibrated to the task and evidence.
  • Human approval as a blanket control. Approval without evidence, authority, and time is a weak signal.
  • Benchmark score as deployment proof. Benchmarks support comparison under stated conditions, not local product safety.
  • Memory as continuity. Continuity requires governed state, not just remembered text.

Fieldbook guidance

Section titled “Fieldbook guidance”

When designing a new agentic system, begin with the domain case. Then look for cross-domain patterns that fit the same shape of work. Use the pattern as a checklist of questions, not as permission to skip local evidence.

Promote a pattern only when it names its failure boundary. A reusable pattern should make the system easier to reason about under stress. If it hides authority, evidence, or ownership, it is not a pattern; it is vocabulary.

Checklist

Section titled “Checklist”
  • Does the proposed pattern appear in at least two domains with similar problem structure?
  • Is the accepted outcome defined for this domain?
  • Are context, authority, verification, state, escalation, and recovery requirements explicit?
  • Does the pattern identify where it stops applying?
  • Are vendor examples treated as implementation evidence rather than proof of universal correctness?
  • Does the design preserve domain-specific obligations around identity, privacy, money, safety, or law?
  • Can failures and corrections feed maintained evaluations or knowledge sources without becoming unreviewed memory?
  • Would a reviewer understand what evidence supports the pattern and what remains uncertain?

References and how they are used

Section titled “References and how they are used”