The primitive

Meet your agents’ smiths.

A smithis one running clone of an agent, scoped to a single end-user. You design the agent once; we run a private smith for each of your users — its own memory, tools, conversations, and identity. It’s the unit of isolation, and the thing every action is recorded against.

The model

One design. A private one per person.

An agent is the reusable design — instructions, model, tools, memory — that you publish as versioned snapshots. A smith is what runs: an isolated clone of that agent for one of your end-users.

The agent is the blueprint in the drawer. The smith is the one at the forge, doing the work for a single person — and keeping everything it learns about them to itself.

Agent · the design
support-concierge
instructionsmodeltoolsmemory
v7 · published
one each
Smiths · one per user
ppriya
live thread
mmarco
2 channels
aalice
312 memories
What a smith owns

Everything a smith knows is its own.

Isolation isn’t a feature you switch on. It’s what a smith is — four kinds of state, sealed to one end-user and read back over the same API you provision them with.

GET /v1/smiths/smt_8f3asealed
Its own memory

Working memory and recall, kept per smith. Conversations resume where they left off, and never bleed into another user's.

scope: smith · working + recall
Its own connections

Each smith's OAuth tool connections are stored server-side, in isolation. The credentials live with the smith, never in your app.

oauth · stored server-side
Its own conversations

Threads across every channel it's reachable on, with one continuous history no matter where the user writes from.

slack · whatsapp · telegram · email
Its own identity

A stable smt_ id and a scoped token. The token carries the tenant, so a smith can only ever see its own state.

smt_… · scoped token
Versions & revisions

Ship to the whole fleet, or just one.

An agent’s published snapshots are versions. Roll a new version out to every smith at once, or pin a single smith to the one it’s on. A smith’s own config history — overrides you make to that one — are its revisions. Two words on purpose.

rollout
agent versionv7 → v8 · published
fleetall smiths → v8
priyapinned to v7
marco · revisiontools += calendar
Identity & provisioning

One human, one smith, per agent.

A smith is identified by your own user reference plus the agent it runs. Provisioning is idempotent: call it with the same reference and you get the same smith back, every time — so you can safely provision on every login.

Group a person’s smiths across agents by that shared reference — that’s your end-user, one tap away in the console.

Modeling your users
provision.ts
// same external_id → same smith
await fetch(BASE + "/v1/smiths", {
method: "POST",
headers: {
Authorization: `Bearer ${PROJECT_TOKEN}`,
"Idempotency-Key": `smith-${user.id}`,
},
body: JSON.stringify({
external_id: user.id, agent_id: "agt_support",
}),
});
// → 201 { id: "smt_…", external_id: "user_123" }

Run a private smith for every user.

Design one agent, provision a smith per end-user, and let the platform keep each one isolated, remembered, and on the record.