Synapse and Locus
A deployment switches each Synapse and Locus service on by configuration, and an environment holds product access of its own, so an operation in the reference can answer that its service is off where you call it. Product availability lists the checks that tell you what is switched on.
Katara Synapse holds an agent’s definition, knowledge and run history. Katara Locus controls the tools that agent can call, the budget it can spend and the actions a person must approve. Cortex supplies model inference.
For example, a support agent can read approved return policies in Synapse, ask a model to prepare a response through Cortex, and request a refund through a tool governed by Locus. A tool permission, a budget and any required human approval must all be current before execution.
Start here
Section titled “Start here”| To do this | Read |
|---|---|
| Find out what is switched on for your environment | Product availability |
| Build an agent that Katara runs | Tutorial: run a managed agent, then Define, test and inspect an agent |
| Act through Locus from an agent you run yourself | Tutorial: act from your own runtime, then Agent identities |
| Give an agent knowledge and memory | Content, collections and memory |
| Control tools, budgets and approvals | Tools, policies and approvals |
| Start runs on a schedule or from events | Schedule agent runs, Signed event sources |
| Measure an agent and promote it to Live | Evaluation, Test-to-Live promotion |
| Choose keys and permissions, and retry safely | Access and API keys |
Every page is also published as plain Markdown at its address with .txt in place of the final slash, and llms.txt indexes them, for agents that read the documentation.
Use the interface or integrate an application
Section titled “Use the interface or integrate an application”The platform at https://platform.staging.katara.com is the workspace for configuring products. The product interface and the API share organizations, environments and authority. Building a client against the API requires code; reviewing a configured action or inspecting a run in the platform does not.
The TypeScript and Python clients use the same product API. A separate provider SDK or a separate Synapse login is not required. Start with access and API keys and the SDK examples.
Current implementation boundary
Section titled “Current implementation boundary”| Area | Implemented API surface | Remaining product work |
|---|---|---|
| Shared account | Organizations, teams, service accounts, scoped keys, consent and budgets, including budgets paid from a wallet | None |
| Synapse knowledge | Content upload and approval, parsing, collections, approved web sources, GitHub repository attachments read at a pinned commit, versioned memory facts, durable ingestion with retention and cleanup, indexing a run’s collections and facts when it starts, graph and vector search, context compaction, image descriptions on a run’s budget | Recall and image-description quality measured against a live model; facts extracted from documents without a person proposing them |
| Synapse agents | Immutable definitions, model selection, simulation catalog, run admission, durable execution, code and browser steps in isolated sandboxes whose workspace lasts the whole run, inspection, cancellation, artifacts, execution bounds, schedules and child agents | None |
| Locus | Tool publication, endpoint verification, grants, sandbox access, policy review, action approvals and governed execution | Tool, code and browser effects outside Live |
| Notifications | Shared personal inbox, preferences, event catalog, delivery-state reads, product producers, and delivery by email, signed webhook, browser push and SMS | None |
| Evaluation | Immutable dataset and rubric versions, exact rubric preview, human review, version revocation, blinded review, judge calibration, promotion evidence, rollback to a prior Live version and judging sampled Live runs | Scored experiments against a live model |
Every row above describes what is built and tested locally. None of it describes what is switched on in a given environment: an interface can be complete and the service behind it not enabled for your account. Product availability lists the checks for each service and what each one proves.
Run admission and a successful API response do not prove that a worker is available or that the task succeeded; the run guide distinguishes acceptance, waiting, completion and uncertain execution.
The product API reference contains the implemented request and response contracts. It excludes proposed endpoints that have no public handler.
Prepare fixed cases and review their criteria with the evaluation material guide.