Skip to main content

Agents

An agent is a service that exposes capabilities to the Svantic mesh. Your ticket system, your billing API, your monitoring service — wrap it with the SDK and it becomes an agent that the mesh can discover, invoke, and orchestrate.

How Agents Work

  1. Your agent registers with the mesh, publishing its capabilities
  2. Users or triggers send requests to the mesh
  3. The mesh plans which agents and capabilities to call
  4. Your agent executes the capability and returns the result
  5. The mesh returns the final response
You write the business logic. The mesh handles routing, planning, and orchestration.

Capabilities

A capability is a single thing your agent can do. Each has:
  • Name — What the mesh calls it (get_ticket, create_order)
  • Description — The LLM reads this to decide when to use it
  • Parameters — JSON Schema defining the inputs
  • Handler — Your async function that does the work
Write descriptions that are specific about inputs, outputs, and when to use the capability. The mesh reads these to decide which capability to call.
For a comprehensive guide on defining capabilities, MCP servers, builtin integrations, and bidirectional execution, see Tools & Capabilities.

Where Agents Run

Agents run on your infrastructure — your cloud, your VPC, your laptop. The mesh coordinates them but never sees your raw data. Your code, credentials, and databases stay with you. This is what makes Svantic usable in regulated industries. The mesh sees capability names and results, not the underlying data or logic.

Multiple Agents Together

The mesh can orchestrate multiple agents in a single workflow:
“Check if customer acme-123 has overdue invoices and create a support ticket if they do.”
The mesh might:
  1. Call billing-agentget_overdue_invoices
  2. Call ticket-agentcreate_ticket
  3. Call slack-agentsend_notification
You don’t write this orchestration logic. Each agent exposes its capabilities. The mesh figures out the plan.

Connectivity

Every dispatch the mesh sends must reach your agent. Svantic supports two connectivity modes:
  • Connected (default) — your agent dials Svantic over a persistent WebSocket. Works anywhere outbound HTTPS/WSS works — behind firewalls, NATs, corporate networks, laptops, CI runners, or ephemeral containers.
  • Hosted — your agent exposes a public HTTPS surface the mesh calls into. Opt in when your agent already runs as an HTTP service that can accept inbound traffic.
You choose per instance_id. Two instances of the same agent type can use different modes.

Connected mode (default)

Connected mode: agent dials Svantic via WebSocket, dispatches pushed bidirectionally You get connected mode by calling new MeshConnector(agent, { svantic_url, client_id, client_secret }) with no public_url. The SDK dials a WebSocket and keeps it open. The mesh pushes dispatch frames down the socket; your agent pushes dispatch_result frames back. When it’s right (almost always):
  • Behind a firewall, NAT, or corporate proxy
  • Developer laptop, CI runner, ephemeral container
  • Zero inbound exposure — outbound-only is a compliance win
  • Easiest onboarding: no ingress, no TLS cert, no reverse proxy

Hosted mode

Hosted mode: Svantic sends HTTPS dispatch to agent, agent returns response Opt in by passing a public_url at registration. Every dispatch is an HTTPS POST from the mesh to {public_url}/send. When to pick it:
  • Your agent already runs as a long-lived HTTP service with inbound traffic
  • You have an existing ingress, LB, or API gateway
  • You prefer request/response and control the infra on both sides
Requirements: Publicly reachable HTTPS URL, /.well-known/agent-card.json served at the root, TLS terminated by you.

Quick guide


Health & Capacity

Svantic monitors two independent signals for every registered agent instance: routing status and connection status.

Routing Status

Determines whether Svantic will send tasks to an agent instance: Agents send periodic heartbeats. If an agent stops heartbeating, Svantic marks it unhealthy and stops routing. After repeated failures, it’s automatically deregistered.

Capacity

Each agent can declare a max_concurrent_sessions limit at registration:
  • 0 (default): unlimited
  • N > 0: Svantic tracks active sessions and stops routing new work once the limit is reached
When capacity frees up (sessions close), the agent becomes available again. Among available agents, Svantic prefers the least-loaded instance.

Connection Status

Reflects the transport link health — drives dashboard indicators:

Health Events


Registration

Registration tells Svantic what your agent can do. Once registered, the mesh can discover your capabilities and route work to your agent.

Quick Start (SDK)

The SDK handles authentication, registration, and connectivity automatically.

Registration Policies

Configurable in the dashboard under Settings → Agent Policy:

Agent Card

Every agent publishes an Agent Card at /.well-known/agent-card.json. The SDK generates this from your define_capability calls.
Best practices: kebab-case names, AI-readable descriptions, one skill per function, JSON Schema with descriptions on every property, semver versioning.

Manual Registration (non-SDK)

If you’re not using the SDK (e.g. Python, Go): 1. Authenticate:
2. Register:
Add "public_url" and "deployment_mode": "hosted" only if your agent is publicly reachable.

Managing Agents

Deregistration removes the instance from routing and cleans up any active session bindings.

Environment Variables