Host the Syntic Agent SDK

The Syntic Agent SDK is a library, not a server, so you host it by embedding it inside whatever process model suits your workload. That flexibility means the same agent code can run behind a web API, inside a background worker, or in a serverless function triggered by an event. What changes between these models is how you manage process lifetime, concurrency, and the connection to api.syntic.ai where Amara runs.

Choosing a process model

Long-lived servers are the most common choice. A single process starts once, keeps warm connections to the Syntic API, and handles many requests over its lifetime. This model amortizes startup cost and makes in-memory session reuse straightforward.

Containers give you the same long-lived model with reproducible dependencies. Package your SDK program with a pinned runtime, set SYNTIC_API_KEY through the orchestrator’s secret mechanism, and scale horizontally by running more replicas behind a load balancer.

Serverless functions suit spiky or event-driven workloads. Because functions are short-lived and may cold-start, avoid relying on in-memory session state between invocations — persist sessions externally instead (see Persist sessions).

Handling concurrency

Each agent run is an independent asynchronous stream, so a single process can drive many at once. Wrap each request in its own query and let the event loop interleave them.

import { query } from "@syntic/agent-sdk";
 
async function handleRequest(prompt: string, cwd: string) {
  let output = "";
  for await (const message of query({ prompt, options: { cwd } })) {
    if (message.type === "result") output = message.result;
  }
  return output;
}

from syntic_agent_sdk import query
 
async def handle_request(prompt: str, cwd: str) -> str:
    output = ""
    async for message in query(prompt=prompt, options={"cwd": cwd}):
        if message.type == "result":
            output = message.result
    return output

Scaling sessions

At scale, treat sessions as data rather than process state. Store each session’s identifier and history in a shared datastore keyed by user or conversation, then resume it on any replica. This keeps your fleet stateless, lets you scale replicas freely, and survives restarts — the connection to api.syntic.ai is re-established per process, but the conversation lives on. Size your replica pool to your expected concurrent runs and monitor API rate limits from the Syntic AI console.