Talon
The control plane for durable agent swarms.
Primitives for the AI native era - durable agents, serverless execution, namespace isolation.
Agent Vanguard IDLE
@Agent Atlas flagged a 40% week-over-week usage drop at Acme Corp.
snowflake.query_usage
logs.search_connector_errors
auth.generate_reconnect_link
Ingress
Session Streaming
IAM
Scheduling
@Agent Vanguard Ask anything
A Real Use Case
A customer-facing agent that keeps running.
One support template. Stripe and HubSpot tools. Named renewal sessions. Weekday wakeups for follow-ups without rebuilding the stack around each workflow.
A reusable template, namespace-scoped knowledge, MCP bindings, and a named renewal session for each operating thread.
The session thread, tool policy, schedule state, and wakeup path even if the worker process or deployment turns over.
SESSION FLOW
Named renewal session
A durable `enterprise-renewals` thread keeps account state, message history, and recovery metadata together.
Scheduled wakeup
Weekday cron wakes the same agent-session pair so follow-up work continues with context instead of restarting cold.
Policy and bindings
Stripe, HubSpot, and namespace knowledge stay attached through policy and bindings rather than one-off glue code.
Active thread enterprise-renewals
id: enterprise-renewals
agent: customer-support
ns: acme
status: active
metadata:
owner: revenue-ops
messages:
- role: user
content: Review renewals due in 14 days.
- role: assistant
content: Drafting account-by-account follow-ups.
stream:
- step: load-knowledge
- step: call-stripe
- step: write-next-message Narrative
Demoing is easy. Operating is infrastructure. Talon exists for the gap between prompt demos and production systems.
Prompts live in code, sessions fragment across services, tool auth drifts, schedules are bolted on later, and every agent becomes a bespoke app.
Gateway routes, worker execution, Postgres-backed state, Pub/Sub dispatch, optional scheduler wakeups, MCP bindings, knowledge, and manifest-defined agent configuration.
Generic workflow systems can retry jobs and persist state. Talon persists agent-native state, named sessions, namespace knowledge, MCP policy, and schedules that wake a specific agent-thread pair.
Operational Features
Managed operations via API and dashboard. Beyond storage and routing: skills, provider failover, internal ops routes, and a UI for inspecting the object graph.
Directory-based skills load from `skills/*/SKILL.md`, parse frontmatter, and register into the unified tool registry alongside built-ins and MCP tools.
Agent specs can select providers by model policy profile, while the runtime can retry across providers with backoff instead of treating one outage as total failure.
The worker exposes an internal `talon-ops` MCP route with scoped access rules, namespace filtering, history limits, and token-based access brokering.
Interfaces
Operate it by API or dashboard.
A gateway API for automation. A UI for exploration, chat, and resource inspection.
Gateway surface HTTP + gRPC
GET /v1/ns/{ns}/agents
POST /v1/ns/{ns}/agents/{agent}/sessions
POST /v1/ns/{ns}/agents/{agent}/sessions/{session_id}/message
GET /v1/ns/{ns}/agents/{agent}/sessions/{session_id}/stream
POST /v1/ns/{ns}/schedules
POST /v1/namespaces/{ns}/mcp-bindings The UI already models namespaces, agents, sessions, schedules, templates, MCP servers, and bindings as navigable resources.
The app includes chat surfaces, streamed step events, gateway URL management, and session-aware navigation.
Talon is not only a library. It is shaping into an operating environment with a gateway, worker, UI, manifests, and internal ops tooling.
How It Runs
Gateway for control. Worker for execution. Server exposes the API. Worker processes dispatch and wakeups. Control plane provides state, delivery, and scheduling.
Deployment shape talon.yaml
gateway:
grpcAddr: 0.0.0.0:50051
control_plane:
database:
driver: postgres
message_broker:
driver: gcp_pubsub
scheduler:
backend: cloud_tasks
worker:
pullMode: true
mcpRoutes:
- /mcp/talon-ops gRPC and HTTP surface for agents, sessions, knowledge, schedules, namespaces, templates, and MCP resources.
Processes session dispatch events, lifecycle invalidations, and scheduler callbacks.
Postgres key-value storage, GCP Pub/Sub transport, and pluggable scheduler backend with security surfaces around gateway and scheduler auth.
From Spec To Runtime
Define, wire, and operate.
Don’t just prompt. Program the runtime.
Template becomes runtime
customer-support Start with a reusable template. Talon resolves it into an agent with effective policy, tool bindings, and dependency tracking.
apiVersion: talon.dev/v1alpha1
kind: AgentTemplate
metadata:
name: customer-support
namespace: acme
definition:
customSpec:
features:
- name: customer_id
type: string
required: true
modelPolicy:
profiles:
- name: primary
model:
provider: openai
name: gpt-4o
temperature: 0.2
systemPrompt: |
You are the support runtime for Acme.
Use customer_id to retrieve context and act safely.
mcpServerRefs:
- stripe-readonly
- hubspot-readonly Definition layer: template, model policy, features, and tool references.
Session stays alive
enterprise-renewals A named session is the durable thread around the agent. Messages, status, and streamed execution remain inspectable between turns and restarts.
id: enterprise-renewals
agent: customer-support
ns: acme
status: active
metadata:
owner: revenue-ops
messages:
- role: user
content: Review renewals due in 14 days.
- role: assistant
content: Drafting account-by-account follow-ups.
stream:
- step: load-knowledge
- step: call-stripe
- step: write-next-message Execution layer: persistent thread, streamed steps, and current status.
Schedules trigger work
renewal-check Schedules do not just launch jobs. They wake a specific agent and session pair so long-running workflows keep continuity.
name: renewal-check
ns: acme
spec:
kind: cron
cron: "0 14 * * 1-5"
timezone: America/Los_Angeles
target:
agent: customer-support
sessionMode: named
sessionId: enterprise-renewals
inputMessage: |
Review accounts renewing in the next 14 days and draft follow-ups.
enabled: true Environment layer: scheduling, wakeups, and operational continuity.
Talon today already includes the hard parts.
Gateway CRUD, session streaming, schedule validation and claiming, namespace-scoped knowledge, MCP bindings, model policy resolution, worker dispatch, and an operational UI are already present in the repo.
Everything In Talon Today
The runtime has three layers. A unified model: define behavior, execute work, and operate the environment.
AgentTemplate, Agent, and Schedule define what should run, with which policy, and when.
Session objects, streamed turns, worker dispatch, and schedule wakeups keep live agent work moving.
Namespace, Knowledge, MCP Server, and MCP Binding provide isolation, context, and tool access policy.
Talon treats sessions, schedules, and namespace policy as one operating model instead of scattered infrastructure decisions.
Use the same runtime to define behavior, recover execution, and keep agent work coherent across restarts and follow-up tasks.
Get Started
Built for durable agent systems. Available now.
Run Talon locally, inspect the runtime model, and see how sessions, schedules, namespaces, and bindings work together in one control plane.