Skip to main content
A Tilde agent has three parts:
  • Your agent code, written in the framework you already use.
  • The Tilde SDK, which connects your code to the gateway and gives it an invocation context.
  • A container or Lambda function that packages the two.
Your code contains no chat provider integration, no provider API keys, and no HTTP server. The gateway supplies all three at runtime.

Example agent

This agent uses the Vercel AI SDK. It is two small files: one connects to Tilde, and one defines the agent and handles a single invocation.
The container needs two environment variables, TILDE_GATEWAY_URL and TILDE_DEPLOYMENT_TOKEN. See Deploy direct agents.

The invocation context

Everything your agent does during an invocation goes through ctx. It is bound to one invocation, and carries that invocation’s short-lived token. The adapter package connects Tilde to the framework’s own objects. convertToAiSdkMessages turns Tilde history into AI SDK messages, and tildeAiSdk adds Tilde’s tools and skills to a call. You still call generate, stream, generateText, or streamText yourself. To use a framework with no adapter, read ctx directly inside run. See Framework integrations.

Lifecycle of a request

Sequence of one request: a message reaches the gateway, passes access checks and request guards, wakes the agent with a short-lived token, the agent calls the LLM through the gateway, replies through a channel tool, and the gateway applies response guards before delivery
Click to zoom
1

A message arrives

A chat provider’s webhook, or your own app through native chat, delivers the message to the gateway.
2

The gateway checks and routes it

The gateway checks that the sender can message this agent, runs request guards in Tilde Enterprise, and picks a ready deployment. See Routing.
3

The gateway wakes the agent

The gateway sends the invocation down the agent’s open HTTP/2 stream, with a short-lived token. The SDK calls your run function.
4

The agent loads its context

The agent reads the conversation history and the channel’s tools through the gateway.
5

The agent calls the model

The LLM request goes to the gateway with a placeholder key. The gateway injects the real credential, forwards the request, streams the response back, and records the usage.
6

The agent replies

The agent calls the channel’s send tool.
7

The gateway screens the reply

The gateway checks the agent’s capabilities, runs response guards in Tilde Enterprise, and records the tool call.
8

The reply is delivered

The gateway sends the reply through the provider’s API, with the connection’s credential.
9

The agent reports

The SDK uploads logs and traces, and reports that the invocation ended.
For a sidecar agent, the sidecar takes the gateway’s place in steps 3 to 7, on loopback.

Lifecycle of an agent

An agent has many deployments over its life. Each deployment is one release of your container, registered in Tilde and tied to a commit. Two rows of steps. First deployment: build, register the deployment, roll out, connect, and serve. Deploying an update: build version two, register it, roll it out beside version one, route new conversations to it, drain version one, and retire it
Click to zoom

First deployment

  1. Build the agent image from your Dockerfile.
  2. Register a deployment with tilde deploy. Tilde registers the agent’s prompts, tools, and skills with it, and returns a deployment token once. The deployment is registered but offline.
  3. Roll out your replicas with the token.
  4. Connect. Each replica dials the gateway and sends ready heartbeats.
  5. Serve. Once a replica is ready, new conversations route to the release.

Deploying an update

An update is a new deployment of the same agent. You never replace a deployment in place.
  1. Build the new image.
  2. Register a second deployment. It has its own token.
  3. Roll out the new release beside the old one. Both stay connected.
  4. Route. In latest mode, new conversations go to the new release as soon as it is ready. In weighted mode, you send it a percentage first.
  5. Drain. Conversations that started on the old release stay pinned to it, so keep it running until they end.
  6. Retire the old deployment. Its token stops working.
To roll back, promote the old deployment. It becomes the serving deployment again, and conversations pinned to the new release stay there. Automate these steps in your pipeline. See Release agents from CI.