Technical buyer guide
Agent infrastructure for systems that have to operate.
Put orchestration, identity, permission, approval, telemetry, cost, and recovery around the model before a convincing demo becomes an operating dependency.
Orchestration decision
Choose the smallest orchestration boundary.
A fixed workflow is easier to test, explain, recover, and price. Add model-directed choice only where the task really varies, and add multiple agents only when separate context, authority, or specialization produces evidence worth the coordination cost.
Deterministic workflow
Use code to own the sequence. A model can classify, extract, compare, or draft inside a bounded step.
One tool-using agent
Use one agent when the next useful step depends on context but the tool, permission, and recovery graph can stay small.
Multi-agent system
Use separate agents only when their context, identity, owner, or evaluation boundary should remain genuinely distinct.
Operating architecture
Eight layers from business trigger to safe recovery.
The model is one component. Each surrounding layer needs a named owner, an enforceable contract, representative tests, and observable failure behavior.
01
Workflow contract
Define the trigger, eligible input, expected state change, accountable owner, excluded work, and stop condition before adding model discretion.
02
Orchestration
Keep stable sequences deterministic. Add model-directed tool or agent choice only where task variability justifies the extra latency, cost, and failure surface.
03
Context and memory
Name the provenance, freshness, scope, isolation, retention, and deletion rule for every record placed into prompts, state, retrieval, or long-term memory.
04
Model task
Bound the reasoning or generation task, version the configuration, validate structured outputs, and test representative and adversarial conditions.
05
Tools and integrations
Use typed arguments, explicit allowlists, timeouts, idempotency, bounded retries, deterministic errors, and a clear downstream system of record.
06
Identity and authority
Give the acting agent a distinct identity, accountable sponsor, least-privilege scope, and explicit delegated, application, or human-approved authority.
07
Telemetry and evaluation
Correlate workflow, model, prompt, tool, identity, version, latency, cost, override, and outcome without capturing sensitive content by default.
08
Containment and recovery
Provide pause, kill, revoke, reconcile, notify, evidence-preservation, rollback or compensation, and controlled re-entry paths.
Identity and approval
Permission is part of the workflow contract.
A tool description tells a model how to ask. It does not decide who may act, which resource is eligible, what consequence is acceptable, or whether a person must approve.
Record these fields for every consequential action
- Acting identity, accountable sponsor, environment, and resource owner.
- Resource, action, scope, data class, reversibility, and expected state transition.
- Delegated, application, deterministic-policy, or human-approved authority.
- Approval context, approver role, timeout, rejection, escalation, and durable resume behavior.
- Token audience, downstream authorization, revocation path, and negative access tests.
Failure model
Design for the expected ways agency fails.
The dangerous path is not limited to a bad final answer. It includes manipulated context, valid tools used badly, hidden privilege, repeated actions, unsafe traces, and partial state changes.
Goal or context hijack
Failure mode: Untrusted content changes the effective task or influences later tool selection.
Control: Separate instructions from data, constrain eligible context, validate tool intent and arguments, and test adversarial records.
Tool misuse
Failure mode: A legitimate tool is used with the wrong resource, scope, parameters, sequence, or consequence.
Control: Put authorization and deterministic policy at the tool boundary, require approval where downside changes, and test denied actions.
Identity and privilege abuse
Failure mode: Shared credentials or broad application access hide the actor and enlarge the blast radius.
Control: Use distinct identities, named sponsors, least privilege, audience-bound tokens, environment separation, revocation, and periodic access review.
Loop and resource amplification
Failure mode: Retries, handoffs, parallel calls, or recursive planning consume time and budget or repeat downstream actions.
Control: Cap turns, wall time, concurrency, retry budget, token and tool spend; add circuit breakers, idempotency, and queue backpressure.
Trace leakage or false audit confidence
Failure mode: Inputs, outputs, tool arguments, or secrets are retained broadly, while important identity or state transitions remain absent.
Control: Define a privacy-aware telemetry contract, capture low-cardinality operational evidence, restrict content capture, and verify audit gaps explicitly.
Partial or harmful action
Failure mode: The model, tool, network, or user-visible delivery fails after some state has already changed.
Control: Carry progress state, make writes idempotent, preserve an action ledger, stop further work, and reconcile or compensate before re-entry.
Observability and audit
A trace is not automatically a safe audit record.
Tracing can make a run debuggable while still leaking prompts, records, tool arguments, outputs, or secrets. It can also omit the acting identity, approval, policy decision, or final system state needed for accountability.
Separate three evidence jobs
- Operations: latency, errors, saturation, queue, retries, token/tool cost, limits, and dependency health.
- Evaluation: task eligibility, output and tool correctness, denials, overrides, recovery, and version regression.
- Audit: actor, authority, resource, action, approval, state transition, integrity, retention, and access.
Release decision
A demo becomes operable when the failure gates pass.
A successful happy path is necessary evidence, but it does not prove permission, denial, privacy, limits, partial-action recovery, or operating ownership.
Permission inventory passes
Every tool action maps to an identity, resource, scope, environment, consequence, approval rule, and revocation owner.
Representative evaluation passes
Success, denial, ambiguity, dependency failure, adversarial input, timeout, and recovery cases meet versioned thresholds.
Approval can wait and resume
Pending state is durable, version-aware, privacy-reviewed, and recoverable when approval takes longer than one request.
Telemetry answers operating questions
The team can find the run, acting identity, version, tool path, failure class, cost, approval, and final state without exposing unnecessary content.
Limits fail closed
Turn, time, concurrency, retry, spend, rate, and queue limits stop new work without duplicating or orphaning completed actions.
Recovery has been exercised
An accountable operator can pause, revoke, contain, reconcile, notify, preserve evidence, and control re-entry during a drill.
Design the stop and recovery path.
Decide who can pause new work, revoke access, preserve evidence, reconcile partial changes, notify affected owners, and approve re-entry. Exercise that path before the agent holds authority the team cannot quickly contain.
Review NIST AI RMF monitoring and recovery guidancePublic proof
Inspect the source and regression contracts.
The OpenClaw Microsoft Teams case links directly to merged upstream changes for identity, strict token validation, delivery limits, recovery, and deterministic human actions. It is public contributor evidence, not a client or service-level claim.
Operational AI infrastructure
6 direct source artifacts
Hardening Microsoft Teams delivery in OpenClaw
A sequence of upstream fixes across identity, allowlists, progressive replies, deterministic human actions, and recovery after partial delivery.
Evidence boundary: This proves the implementation and regression contract, not every possible Microsoft tenant topology.
Runtime-compatible Teams allowlist keys
Merged OpenClaw pull request #41838 documents the Graph and Bot Framework identifier mismatch, the bounded fallback, and six focused allowlist tests.
Open merged pull requestStrict Bot Framework and Entra token validation
Merged pull request #56631 adds a strict Entra service-token path while retaining issuer, JWKS, audience, and service URL checks, with focused authorization tests.
Open merged pull requestConfigurable progressive reply delivery
Merged pull request #56134 wires Teams block-streaming configuration through validation and dispatch, backed by the public targeted test run recorded in the PR.
Open merged pull requestLong-response fallback without duplicate text
Merged pull request #59297 records the partial-stream failure mode and tests fallback delivery of only the remaining suffix.
Open merged pull requestDeterministic Adaptive Card action handling
Merged pull request #60431 adds an explicit handler and regression test for Adaptive Card Action.Submit activities that were previously dropped.
Open merged pull requestConversation state preserved through pairing approval
Merged pull request #60432 stores the conversation reference before the pairing return path and verifies that behavior with a focused authorization test.
Open merged pull requestPrimary sources
Current references behind the framework.
Framework and cloud documentation supports product-specific behavior. NIST, MCP, OpenTelemetry, and OWASP support risk, identity, protocol, telemetry, and recovery decisions. None is a Digital Meld outcome claim.
Workflow-versus-agent boundary and the latency, cost, predictability, and flexibility tradeoff.
Approval interruptions, resumable state, delayed decisions, and versioning considerations for pending work.
Agent and function-tool guardrail boundaries, tripwires, and parallel-versus-blocking execution behavior.
Run, model, tool, handoff, guardrail, and custom spans plus explicit sensitive-data capture controls.
Current agent identity, blueprint, sponsor, governance, protection, lifecycle, and authorization concepts.
Token audience validation, no token passthrough, confused-deputy controls, authorization, consent, and audit risks.
Common span, metric, log, and event naming; status and maturity still need to be checked for each convention used.
Human-AI roles, monitoring, third-party risk, appeal and override, incident response, recovery, change management, and decommissioning.
Current threat categories for goal hijack, tool misuse, identity and privilege abuse, agentic supply chains, and unexpected code execution.
Next decision
Bring the workflow, tools, identities, and failure boundary.
Digital Meld will map the operating contract, choose the smallest useful orchestration, and define the permission, evaluation, telemetry, cost, and recovery evidence required before more autonomy is justified.