The control plane for durable agent swarms.

Primitives for the AI native era - durable agents, serverless execution, namespace isolation.

Worker 01 @Agent Atlas

Tool execution + retrieval

Worker 02 @Agent Kestrel

Long-lived session replay

Worker 03
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
Gateway
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.

FIG 0.2
What the team defines

A reusable template, namespace-scoped knowledge, MCP bindings, and a named renewal session for each operating thread.

FIG 0.3
What Talon keeps alive

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.

FIG 0.4
What breaks without a control plane

Prompts live in code, sessions fragment across services, tool auth drifts, schedules are bolted on later, and every agent becomes a bespoke app.

FIG 0.5
What Talon centralizes

Gateway routes, worker execution, Postgres-backed state, Pub/Sub dispatch, optional scheduler wakeups, MCP bindings, knowledge, and manifest-defined agent configuration.

FIG 0.6
Why this is not just Temporal or generic infra

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.

FIG 0.7
Skills platform

Directory-based skills load from `skills/*/SKILL.md`, parse frontmatter, and register into the unified tool registry alongside built-ins and MCP tools.

FIG 0.8
LLM resolution + failover

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.

FIG 0.9
Talon ops surface

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
Namespace explorer UI

The UI already models namespaces, agents, sessions, schedules, templates, MCP servers, and bindings as navigable resources.

Chat + step streaming

The app includes chat surfaces, streamed step events, gateway URL management, and session-aware navigation.

Operational posture

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
Gateway

gRPC and HTTP surface for agents, sessions, knowledge, schedules, namespaces, templates, and MCP resources.

Worker

Processes session dispatch events, lifecycle invalidations, and scheduler callbacks.

Control plane

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

Start with a reusable template. Talon resolves it into an agent with effective policy, tool bindings, and dependency tracking.

customer-support
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

A named session is the durable thread around the agent. Messages, status, and streamed execution remain inspectable between turns and restarts.

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
Execution layer: persistent thread, streamed steps, and current status.
Schedules trigger work

Schedules do not just launch jobs. They wake a specific agent and session pair so long-running workflows keep continuity.

renewal-check
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.

FIG 1.0
Definition

AgentTemplate, Agent, and Schedule define what should run, with which policy, and when.

FIG 1.1
Execution

Session objects, streamed turns, worker dispatch, and schedule wakeups keep live agent work moving.

FIG 1.2
Environment

Namespace, Knowledge, MCP Server, and MCP Binding provide isolation, context, and tool access policy.

FIG 1.3 State, routing, and wakeups belong together.

Talon treats sessions, schedules, and namespace policy as one operating model instead of scattered infrastructure decisions.

FIG 1.4 Built for real systems, not demo threads.

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.