Agents · Apps · Bots · Coding tools

Give every AI use case one identity and one operating policy.

Your company may call them agents, assistants, bots or AI features. Talon treats each one as a concrete agent identity: one file, one vault-bound key, one derived tenant, and one effective policy for cost, reliability, data, tools, egress and evidence on intercepted paths.

Run the 60-second demo Choose an integration path Compare approaches

one agent.talon.yaml
= one AI use case
= one vault-bound agent key
= one derived tenant
= one effective policy

request
→ authenticate agent
→ evaluate policy
→ route / deny / redact / filter
→ sign the evidence

Agent identityShared budgetsReliabilityEffective policySessionsEvidence

Category and implementation

AI use case is the public object. Agent is the shipped Talon object.

A buyer should not have to learn a new workload noun. Publicly, Talon operates AI use cases. In configuration, authentication, policy, evidence and cost attribution, one Talon agent now represents that use case consistently.

One real use case first

Start with the support bot, coding workflow or product feature that already needs cost, reliability or policy control.

Keep the orchestrator

Talon does not decide tasks, spawn subagents or replace LangGraph, Claude Code, Codex or your application logic.

Unify the operating layer

Move runtime budgets, identity, policy decisions, provider paths and evidence out of one-off application code.

Identity contract

The application presents an agent key, not a free-form identity claim.

agent.key.secret_name points to one encrypted vault secret. Talon resolves the presented key to the agent and tenant, rejects unknown keys, and prevents the request from acting as a different agent. The admin key remains a separate authority.

Authentication reference Configure an agent

agent:
  name: customer-support
  tenant_id: acme
  key:
    secret_name: customer-support-talon-key

# bearer key → customer-support → acme
# body/header cannot substitute another identity

Four questions

The control plane should answer what the app alone cannot.

Question	Talon pillar	Current proof
What is this AI use case spending?	Cost control	Per-agent cost views, session cost and budget-denial evidence.
What failed and where did execution go?	Reliability	Policy-checked fallback attempts and terminal evidence on supported transient failures.
Which rules apply to this use case?	Shared policy	Organization baseline plus one agent override, resolved for models, providers, cost, PII, tools and egress.
What happened in this multi-request run?	Session understanding	Agent-scoped asserted-session list, export, cost and verification across allowed provider routes.

Effective policy

Use one policy snapshot across the complete provider path.

The organization baseline and agent override resolve into the same effective policy used by the primary route, every fallback candidate, budget reporting and evidence. Organization PII, provider/model, tier and egress boundaries cannot be weakened by an agent.

Shared policy model Policy examples

organization policy
        +
one agent override
        ↓
resolved effective policy
        ↓
primary route + fallback + costs + evidence

Current operator path

Use the CLI and evidence model that actually ship.

Operators can inspect cost, list session evidence, open one decision, verify integrity and confirm the policy identity with shipped CLI surfaces.

talon costs --agent customer-support

talon audit list --session sess-feature-4711

talon audit show <evidence-id>

talon audit verify <evidence-id>

Action boundary

Agentic does not mean universally observable.

Talon can govern provider-bound traffic, tool schemas visible to the gateway and MCP/tool calls routed through its interception path. Local shell commands, file edits, browser actions and direct APIs that bypass Talon remain outside the control plane.

through Talon
→ authenticated agent
→ policy can run
→ evidence can be written

bypasses Talon
→ invisible
→ uncontrolled by Talon

Current boundary

Agent identity is shipped; one-process fleet discovery is not.

A gateway process currently loads one default agent file. Serving and safely reloading many agent files through agents_dir remains active roadmap work. The identity, key binding and effective-policy contract described here is already enforced.

Adopt incrementally

Put one authenticated AI use case on the common path.

Create its agent file, mint the vault-bound key, route provider traffic through Talon, inspect what it costs and why requests are allowed or denied, then expand to the next use case.

Add Talon to an app Start with cost Start with sessions