Agents & Delegation

AgentLattice treats every AI agent as a first-class identity -- a registered entity with a name, a set of capabilities, and a complete audit history. If an agent can take actions in your infrastructure, it should have an identity in AgentLattice. This is the foundation that makes policy enforcement, approval workflows, and audit trails possible.

What is an Agent?

An agent in AgentLattice is any software entity that performs actions on behalf of your workspace: a code review bot, a deployment pipeline, a data processing workflow, an AI assistant with tool access. Each agent gets:

• A unique identity tied to your workspace
• An API key used to authenticate every action
• Capabilities -- the set of action types the agent is allowed to perform
• An audit trail -- every action the agent takes is recorded with tamper-evident hashing

Agents are not limited to a specific framework. Whether you are building with LangChain, CrewAI, AutoGen, a custom Python script, or a simple cron job, any code that calls the AgentLattice SDK is a governed agent.

Registering Agents

You can register agents in two ways:

Via the dashboard: Navigate to Settings → Agents and create a new agent. The setup wizard walks you through four steps:

1. Name — Give your agent a recognizable name (e.g., langchain-data-pipeline, claude-code-reviewer)
2. API key — An API key is generated. Copy it — you will not see it again
3. Connect — Choose how you will connect your agent:
   • Write gate() manually — 3 lines of code in the TypeScript or Python SDK. Best for new agents you are building from scratch
   • Python (al-instrument) — Run al-instrument agent.py --apply --register --key <your-key> on your existing LangChain agent. The CLI performs an AST transform and registers the agent automatically
   • TypeScript (al-instrument-ts) — Run al-instrument-ts agent.ts --apply --register --key <your-key> on your Claude SDK, Vercel AI, or OpenAI TypeScript agent
   • Any framework (/instrument skill) — Open Claude Code in your agent directory and run /instrument. Works with CrewAI, AutoGen, LangChain JS, and any custom pattern
4. Verify — For SDK-connected agents, fire a test event from the dashboard to confirm the connection. For CLI-instrumented agents, run your agent and check the activity feed

This is the typical path for long-running agents managed by your platform team.

Via the SDK: For programmatic registration or automated provisioning, use the SDK to create agent configurations as part of your deployment pipeline.

Once registered, the agent authenticates with its API key on every request. The key is scoped to your workspace -- an agent from one workspace cannot interact with another workspace's policies or audit trail.

Agent Types

Long-Running Agents

These are your persistent workhorses: a CI/CD bot that runs on every PR, a monitoring agent that checks system health, a customer support agent that operates during business hours. They have stable identities, fixed capability sets, and long-lived API keys. You register them once and they run until you deactivate them.

Ephemeral Agents

Ephemeral agents are short-lived, scoped sub-identities created at runtime. A parent agent spins one up for a specific task, gives it exactly the permissions it needs, and it disappears when the job is done. Think of them as capability-scoped temp workers.

Ephemeral agents are invisible in your dashboard and agent lists -- they exist purely as an internal mechanism for safe delegation. Their lifecycle is fully automatic: cleanup happens whether the task succeeds, fails, or the process crashes.

Delegation Chains

Delegation is the mechanism that makes AgentLattice unique in the AI governance space. No other framework offers scoped, audited, lifecycle-managed sub-agent creation.

The core idea: a parent agent can create a child agent with narrower capabilities and a bounded lifetime. The child can only do what the parent explicitly allows, and only for as long as the parent specifies.

Why Delegation Matters

Principle of least privilege for AI. When your orchestrator agent fans out work to sub-agents, each sub-agent should only have access to the specific capabilities it needs. A data reader should not be able to write results. A notification sender should not be able to read sensitive data. Delegation enforces this structurally, not by convention.

Full audit chain. Every action taken by a delegated agent traces back through the delegation chain to the original parent. Your audit trail shows not just "what happened" but "who authorized whom to do what." When an auditor asks "how did this agent get permission to access that data?" the answer is in the chain.

Automatic cleanup. Delegated agents have a time-to-live (TTL). When the TTL expires, the agent is deactivated and its API key becomes useless. If the parent process crashes, a background sweep catches orphaned children within 60 seconds. There is no state to leak.

Escalation prevention. Scope narrows monotonically at each level of delegation. A child can never have more capabilities than its parent. A grandchild can never have more than the child. This is enforced server-side -- a compromised child API key cannot escalate privileges through further delegation.

The delegate() Method

The SDK provides a clean callback-based pattern (TypeScript) or context manager (Python) for delegation:

const al = new AgentLattice({ apiKey: process.env.AL_API_KEY });

const result = await al.delegate("data-processor", {
  capabilities: ["read_data", "write_results"],
  ttl: 300,  // 5 minutes
}, async (sub) => {
  await sub.execute("read_data", { metadata: { rows: 100 } });
  return sub.execute("write_results");
});

al = AgentLattice(api_key=os.environ["AL_API_KEY"])

async with al.delegate("data-processor",
    capabilities=["read_data", "write_results"],
    ttl=300
) as sub:
    await sub.execute("read_data")
    await sub.execute("write_results")

Key properties of delegate():

The child agent's scope is enforced server-side. If the child attempts an action outside its granted capabilities, the request is rejected with a 403. The SDK always includes delegation context headers, so every child action is linked to its delegation chain in the audit trail.

Chaining Delegations

Delegated agents can delegate further, creating multi-level chains. Scope narrows at each level:

await al.delegate("orchestrator", {
  capabilities: ["read_data", "write_results", "notify"],
  ttl: 600,
}, async (orchestrator) => {
  return orchestrator.delegate("writer", {
    capabilities: ["write_results"],  // subset of orchestrator's scope
    ttl: 120,
  }, async (writer) => {
    return writer.execute("write_results");
  });
});

If the child requests capabilities outside its parent's delegated scope, the server rejects with DELEGATION_SCOPE_EXCEEDED. Circular delegation chains (A delegates to B, B delegates to C, C delegates back to A) are detected and prevented at creation time.

Parallel Fan-Out

For workloads that benefit from concurrency -- sharded data processing, multi-source retrieval, parallel analysis -- AgentLattice provides a parallel() helper:

const results = await AgentLattice.parallel([
  al.delegate("reader-1", { capabilities: ["read_data"], ttl: 60 }, async (sub) => {
    return sub.execute("read_data", { metadata: { shard: 1 } });
  }),
  al.delegate("reader-2", { capabilities: ["read_data"], ttl: 60 }, async (sub) => {
    return sub.execute("read_data", { metadata: { shard: 2 } });
  }),
]);

Each delegation manages its own lifecycle independently. If one child fails, the others continue. All children are cleaned up regardless of outcome.

Safety Guarantees

AgentLattice also rate-limits ephemeral agent creation: a maximum of 10 active children per parent agent. This prevents self-replication attacks from a compromised API key.

Viewing Active Delegations

The Policies page includes an Active Delegations section showing all current parent→child delegation relationships for your workspace. Each row shows:

• Parent — the agent that granted the delegation
• Child — the agent that received delegated authority
• Scope — the action types the child is authorized to use
• Expires — when the delegation expires (or "Permanent" for indefinite delegations)

This gives operators full visibility into which agents have delegated authority and what scope they hold, without needing to inspect each agent individually.

Next Steps

• Policies: Define what actions require approval, what gets auto-approved, and what gets denied. See Policies & Approvals.
• MCP Integration: Let your AI assistant manage agents and review activity through natural language. See MCP Integration.
• Security: Understand the threat model and how delegation chains are protected. See Security.