Own the intelligence.Ship the experience.Skip the infrastructure rebuild.
Latch is the agent backend your SaaS product runs on. Ship agent features your customers use: behind your auth, on your database, with your choice of model.
The gap
Take a jump start to production.
Getting a response from a model is the easy part. Getting it to production is where the real work begins: conversation history that survives a refresh, runs that recover from crashes, that passes an audit, approvals before destructive actions, and tools connected without exposing credentials.
What starts as a two-week prototype can turn into two quarters of building infrastructure that isn't your product.
Message history
Durability
Tenant isolation
Approvals
Connectors
Latch is that platform, out of the box — embedded in your stack, not replacing it.
AX first harness
Built around how people actually delegate work to an agent
Conversation history
Persisted messages with three separate views: , , . Internal context reaches the model without leaking into the chat.
Durability
, , , , . A run whose node dies is reclaimed and resumed. Plain TypeScript and your database, no workflow engine to operate.
- 09:00Overnight sync done. Three deals need a nudge.
- 14:00Northwind renews in 30 days. Draft is ready.
- 19:00Two invoices cleared. Nothing needs you today.
Scheduling
Agents that wake up on their own. In-process loop or a serverless route; the same machinery that resumes stalled runs runs your recurring work.
Connectors
servers as tools, behind a per-tenant and a vault-brokered auth flow including . Credentials never reach the model, the logs, or your telemetry.
Archive 4 deals?
Approvals
Read freely, write with confirmation. The turn pauses, the human decides, the turn continues: as message state, not suspension machinery. This is what makes an agent shippable to real customers.
Memory
Agents that stop asking users to re-explain themselves. A every turn, an they search on demand, and background that keeps it honest.
Usage and cost
Token usage and computed cost recorded per message, per run, and in a ledger, behind a you control. Per-tenant is a query.
Each tenant’s activity flows into its own protected data store. Data stays within separate boundaries.
Multi-tenancy
Your identity defines who owns each conversation. Latch carries that scope into storage, keeping each customer’s history, runs and usage separate. Your product stays in charge of permissions.
The API
All of it looks like this.
Two files. Your auth stays your auth, your database stays your database, and the return value is a .
import { createRuntime, defineAgent } from "@intentface/latch-core";
import { anthropic } from "@ai-sdk/anthropic";
// Your identity type. Latch never interprets it.
interface Principal {
orgId: string;
userId?: string;
}
export const runtime = createRuntime<Principal>({
storage, // your Postgres or SQLite
context: ({ principal }) => ({ orgId: principal.orgId }),
agents: {
assistant: defineAgent(() => ({
model: anthropic("claude-sonnet-5"),
instructions: "You are a helpful assistant.",
})),
},
});No workflow cluster, no separate agent service. Runs live in the application and database you already operate.
Execution
A quick answer shouldn’t need a whole computer.
Use Latch for simple answers, tool-using agents, code execution or a full computer. Choose what each agent needs, and expand when its job grows.
Start with a model call. Add tools when the agent needs to act, an isolate when it needs to compose code, and a computer when it needs an operating system. Choose per agent, without rebuilding the product around a single execution shape.
In Code Mode, the agent writes JavaScript against a typed API and composes tool calls inside an isolate. Fetch the accounts, compare their usage, and prepare the report in code, instead of asking the model to coordinate every step separately.
What you own
Your infrastructure. Your models. Your data. Your exit.
No model gateway
Pick any provider, per agent. Swap without touching product code.
Your application stays the system of record
Runs, messages, approvals, usage and cost live in your database, beside your product data. Your team can query them, build on them, and keep them when your choice of model changes.
No lock-in by design
Storage, durability, auth, file storage, scheduling: every one is a seam with a default you can replace. Postgres or SQLite. Inline or a queue. Our auth? There isn't one. You bring yours.
Your product stays yours
Your UI, your brand, your permissions model. Your users never learn Latch's name.
Headless means the experience is yours to design.
Latch has no opinion about how your agent looks. Bring your UI, your data, your workflows: the runtime streams typed events and you render them however your product already renders things.
Or don't build a UI at all: ship your agent into Slack, Telegram or WhatsApp and let people talk to it where they already are.
Archived 4 stale deals.
Undo#revenue
Pipeline 9:02
Archived 4 stale deals.
Mia 9:04
Do the same for Q2.
The short answers
How Latch compares
Built for your existing stack.
| Compare by | LatchInside your product | Vercel AI SDKLatch’s foundation | Agent frameworksLangGraph and Mastra | Managed runtimesMicrosoft Foundry and AWS AgentCore |
|---|---|---|---|---|
| Best fit | Agents inside an existing SaaS product. | Build your own agent backend. | Graph and workflow orchestration. | Cloud-operated agents. |
| State | Your Postgres or SQLite, beside product data. | Your database; you build persistence. | Checkpoints or memory in a configured store. | Foundry standard: your Azure storage. AgentCore: session state plus optional memory. |
| Runtime | Your application. No extra agent service. | Your application. | Self-hosted or hosted deployment. | Vendor-run; your cloud configuration. |
| Tenancy | Owner-scoped storage. Your app controls authorization. | Scoping and access checks are yours. | LangGraph: thread IDs. Mastra: configurable auth and resource scoping. | Cloud isolation. AgentCore’s user-to-session mapping is yours. |
| You take on | You deploy and maintain Latch with your application. | Persistence, recovery and cost accounting. | Framework state and tenancy integration. | A separate cloud service and operating model. |
A framework is a better fit when complex orchestration is the product. A managed runtime fits teams that want cloud-operated execution. Latch fits teams bringing agents into a product they already own and operate.
Don't spend the rest of the year building infra. Ship agents this month instead.
The agent harness that runs inside your product. Built and run by Intentface.