Agentic infrastructure
Give AI agents less authority, better tools, and stronger evidence.
Design agent nodes around bounded goals, delegated identity, typed tools, governed memory, deterministic policy, human checkpoints, budgets, and distributed traces.
An agent node turns model output into actions. It may query chain state, schedule GPU work, call APIs, modify infrastructure, or coordinate remote agents. The model is therefore one component inside an authority system. Policy, identity, tool mediation, evidence, and stopping conditions must remain deterministic and observable.
Define a narrow task envelope: allowed goals, tools, data, time, cost, and approvals. Give each task a service identity and short-lived capabilities instead of inheriting a human’s broad credentials. Separate planning from execution. The model proposes; policy validates; a sandboxed tool acts; a verifier evaluates; and the node decides whether to continue.
Treat tool output as untrusted input. Retrieved text can attempt to override instructions, and remote services can return malformed or misleading data. Use typed schemas, allowlisted destinations, bounded responses, provenance labels, and control instructions that cannot be rewritten by content. Memory needs retention, access, correction, and deletion rules; a vector store is not a security boundary.
Evaluate traces, not only final answers. Test malicious retrieved content, partial permissions, stale node data, unavailable tools, repeated loops, and ambiguous goals. Canary model, prompt, tool, and policy changes independently. High-impact actions—signing, publishing, spending, deletion, or infrastructure change—should have explicit approval and rollback boundaries.
Proposal is not permission
Every tool call should carry a task identity, validated arguments, scoped capability, cost budget, policy decision, result evidence, and a clear stop or escalation path.
Autonomy with brakes and receipts
The node should explain every transition from goal to action.
Map
Define context, impact, users, data, dependencies, and unacceptable outcomes.
Open guide →Plan
Generate a bounded proposal with named tools, assumptions, and expected evidence.
Open guide →Policy
Validate identity, permission, parameters, budget, destination, and approval requirements.
Open guide →Act
Execute through a constrained tool or remote node without exposing broad credentials.
Open guide →Verify
Check result, side effects, evidence, and whether the task state actually advanced.
Open guide →Manage
Stop, retry, escalate, revoke, or recover while preserving an auditable trace.
Open guide →Make the hidden assumptions visible.
Each answer should map to a test, metric, policy, or runbook—not merely to a design claim.
A general shell combines many high-impact capabilities and makes validation difficult. Narrow tools express intent, constrain parameters, and produce clearer evidence.
Irreversible, high-value, external, or uncertain actions: signing, spending, publishing, deletion, permission changes, or infrastructure modification. Approval should bind to the exact proposed payload.
They can, but remote services need authenticated capabilities, data minimization, timeouts, schema validation, and task receipts. Reachability alone is not trust.
Separate short-term task state, long-term preferences, retrieved evidence, and secrets. Apply identity at retrieval, minimize retention, preserve provenance, and support correction and deletion.