---
title: Latch — the agent harness that runs inside your product
description: >-
  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.
url: 'https://www.intentface.com/latch'
site: Intentface
---

# Latch

> The agent harness that runs inside your product.

**Make your product agentic with Latch**
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.

## 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, tenant isolation 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.

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: what you store, what the model sees, what the user sees. Internal context reaches the model without leaking into the chat.

### Durability

Lease, heartbeat, reaper, fencing, checkpointing. A run whose node dies is reclaimed and resumed. Plain TypeScript and your database, no workflow engine to operate.

### Scheduling

Agents that wake up on their own. In-process loop or a serverless cron route; the same machinery that resumes stalled runs runs your recurring work.

### Connectors

MCP servers as tools, behind a per-tenant allowlist and a vault-brokered auth flow including OAuth. Credentials never reach the model, the logs, or your telemetry.

### 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 compiled index every turn, an episodic store they search on demand, and background consolidation that keeps it honest.

### Usage and cost

Token usage and computed cost recorded per message, per run, and in a ledger, behind a pricing seam you control. Per-tenant COGS is a query.

### 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.

## Glossary

**what you store** — The lasting record of messages, tool calls, and results, separate from the views shown to the model or the user.

Example: A long conversation can be summarized for the next turn without deleting its original messages.

**what the model sees** — The instructions and conversation material assembled for a model turn. It can include internal context that never appears in the chat.

Example: The agent can receive a private instruction alongside a summary of earlier messages.

**what the user sees** — The customer-facing view of stored history, with internal and redacted messages filtered out.

Example: Your chat shows the answer while keeping internal instructions out of the interface.

**Lease** — A temporary claim that gives one worker ownership of a run. The worker must renew it to keep that ownership.

Example: If a worker disappears, its claim expires so another worker can take over.

**heartbeat** — A regular renewal of the worker’s lease, signaling that it is still handling the run.

Example: When renewals stop, the lease expires and the run can be recovered.

**reaper** — A periodic sweep that finds expired leases and releases abandoned runs for recovery.

Example: A crashed worker’s unfinished run becomes available for a new worker to resume.

**fencing** — An ownership check that blocks writes from a worker whose claim is no longer valid.

Example: An old worker wakes up late; its stale writes cannot overwrite the new owner’s progress.

**checkpointing** — Saving enough state to continue a run after its process stops. Recovery uses persisted history.

Example: A replacement worker picks up the saved task instead of losing the conversation.

**cron** — A scheduled trigger that invokes work at regular times.

Example: A morning trigger starts your daily account review, even when no user is in the app.

**MCP** — A standard interface through which an agent can discover and call tools exposed by another service.

Example: Connect a CRM tool server so the agent can look up an account through a defined tool.

**allowlist** — An explicit list of what is permitted. Anything outside the list is unavailable.

Example: One tenant can use its CRM connector without gaining access to another tenant’s tools.

**OAuth** — A way to authorize access to another service without giving the agent the user’s password.

Example: A user connects their account; the connector handles credentials outside the model context.

**compiled index** — A compact view of remembered information, prepared for inclusion in each model turn.

Example: The agent receives the user’s established preferences without searching every past conversation.

**episodic store** — A searchable collection of memories extracted from past interactions.

Example: When a user refers to a previous decision, the agent can search for the relevant memory.

**consolidation** — Background processing that organizes extracted memories and rebuilds the compact index used in later turns.

Example: New preferences are incorporated into memory after a conversation becomes idle.

**pricing seam** — The replaceable part of the system that maps measured usage to a cost.

Example: Your own rate calculation can account for the model pricing that applies to your product.

**COGS** — The direct cost of providing your service. Per-tenant usage records help attribute model costs to each customer.

Example: Compare a customer’s model spend with the revenue from their subscription.

**tenant isolation** — Keeping each customer’s stored conversations, runs, and usage within its own scope.

Example: Two companies use the same product while each sees only its own conversation history.

**agent harness** — The software around a model that manages its tools, conversation state, and execution inside your product.

Example: The model chooses an action; the harness runs the tool and saves the result.

**V8 isolate** — An isolated JavaScript execution context used to run code without starting a whole operating system.

Example: The agent composes several tool calls into one piece of JavaScript.

**microVM** — A lightweight virtual machine that provides an operating system for work that needs one.

Example: A task needs a filesystem and a Python process, so it runs in a Linux environment.

**streaming Response** — An HTTP response that delivers output incrementally as it becomes available.

Example: Your interface can show the beginning of an answer while the rest is still being generated.

## All of it looks like this.

Two files. Your auth stays your auth, your database stays your database, and the return value is a streaming Response.

`latch.ts`

```ts
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.",
    })),
  },
});
```

`route.ts`

```ts
// One route. The return value is a streaming Response.
export async function POST(request: Request) {
  const { chatId, message } = await request.json();
  const principal = await authenticate(request); // yours

  return runtime.handleChat({ agent: "assistant", chatId, principal, message });
}
```

No workflow cluster, no separate agent service. Runs live in the application and database you already operate.

## Execution ladder

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.

| Rung | Shape | When |
| --- | --- | --- |
| L0 | Model calls | Use Latch to summarize a conversation or classify a lead with one model call. Keep the response and usage in your product, without a tool loop or sandbox. |
| L1 | Agents with tools | Give a Latch agent tools to look up customers, check plans and update your CRM. It runs the model-and-tool loop inside your Node application. |
| L2 | Code Mode | Use Latch’s Code Mode when a task needs several tools working together. The agent writes JavaScript to fetch accounts, compare usage and build a report in an isolate. |
| L3 | A full computer | Connect a Linux microVM when your Latch agent needs files, Python or system tools. Give that agent a computer while simpler agents keep their lighter setup. |

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.

## 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.

## FAQ

### Which model providers can I use?

Use a model compatible with the Vercel AI SDK. Latch accepts a model object per agent and includes optional integrations for OpenAI, Anthropic and Google. Provider-specific tools and reasoning settings depend on the integration.

### Which databases does Latch support?

Postgres and SQLite ship with Drizzle adapters and migrations. To use another database, implement Latch’s storage adapter interface.

### Does Latch replace our authentication?

No. Your app authenticates the request and passes its identity to Latch. You define how that identity maps to an owner key, which scopes stored data. Your app still decides what the caller is authorized to do.

### Do I need a workflow engine?

No. Enable Latch’s durability option and schedule its recovery sweep. Leases, heartbeats and ownership checks let another worker resume a stalled run from persisted history in your database.

### Can we run Latch on serverless?

Yes. The runtime keeps run state in your database. You still need a scheduled trigger for recovery and recurring work, and must account for your host’s execution limits. A long-running Node process can use the built-in interval scheduler instead.

### Can we add Latch to one feature first?

Yes. Register one agent and connect it to a route, your auth and your database. Add more agents and tools as needed; the rest of your backend can stay as it is.

### Do our customers need a new interface or account?

No. Latch runs behind your product’s interface and authentication. You decide how conversations, approvals and results appear; customers do not need a separate Latch account.

### How do we control what an agent can change?

You choose the tools each agent can access and which actions require approval. The agent can propose a change, your interface asks the user to confirm, and the turn continues after their decision. Your application remains responsible for authorization.

### Does customer data leave our infrastructure?

Latch’s runtime and stored state stay in your environment. Requests to external model providers and tools can send data outside it. The providers and integrations you choose determine where that data goes.

### Can we track AI cost by customer?

Yes. Latch records token usage per message and run, plus an owner-scoped usage ledger. Configure model rates to calculate cost; without a matching rate, recorded cost is zero. Customer billing remains part of your product.

### What happens if we change models or move away from Latch?

You can change the model configured for each agent, then test its prompts and tools with the new provider. If you replace Latch, your data stays in your database, but you will need to adapt its schema and runtime integration to the replacement.

### How do we get started?

Book a technical deep-dive. Bring a customer workflow and an overview of your stack so we can assess the integration and agree on a starting point.

## Built for your existing stack.

### Latch

Inside your product

Agents inside an existing SaaS product.

- **State:** Your Postgres or SQLite, beside product data.
- **Runtime:** Your application. No extra agent service.
- **Tenancy:** Owner-scoped storage. Your app controls authorization.
- **You take on:** You deploy and maintain Latch with your application.

### Vercel AI SDK

Latch’s foundation

Build your own agent backend.

- **State:** Your database; you build persistence.
- **Runtime:** Your application.
- **Tenancy:** Scoping and access checks are yours.
- **You take on:** Persistence, recovery and cost accounting.

### Agent frameworks

LangGraph and Mastra

Graph and workflow orchestration.

- **State:** Checkpoints or memory in a configured store.
- **Runtime:** Self-hosted or hosted deployment.
- **Tenancy:** LangGraph: thread IDs. Mastra: configurable auth and resource scoping.
- **You take on:** Framework state and tenancy integration.

### Managed runtimes

Microsoft Foundry and AWS AgentCore

Cloud-operated agents.

- **State:** Foundry standard: your Azure storage. AgentCore: session state plus optional memory.
- **Runtime:** Vendor-run; your cloud configuration.
- **Tenancy:** Cloud isolation. AgentCore’s user-to-session mapping is yours.
- **You take on:** 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.

Contact: https://www.intentface.com/contact