Your harness, in production

Every agent is a model in a harness. Something runs its loop, hands it tools, decides what it sees, remembers for it, gives it somewhere to work and lets people reach it. Glove has a primitive for each of those. Glove Foundry adds what turns a harness into a system: an agent per user, conversations, schedules, inbound channels, approvals and an API.

On a laptop, one command runs all of it. glove foundry dev starts the runtime and an inspector at localhost:4141, and the agent answers. This post is about what happens next.

What production asks of an agent.

Taking a web app to production mostly means more copies and a database. An agent asks for different things, and a harness makes each of them concrete.

• State that outlives the process. Foundry runs every turn in a fresh process, so a crash in one turn can’t corrupt the next. Instances, conversations, schedules and memory live in files or a database, and they need a disk that is still there after a deploy.
• One copy, not five. Every Foundry runtime arms the schedules it finds. Two copies sharing a store send every reminder twice.
• Model calls you can see. An agent makes dozens of calls for one task. When one fails or costs too much, you want the call itself, not a line in a log.
• Browsers, sandboxes and mail as services. A coding agent needs a computer to run code on. A personal agent needs a browser that keeps its logins, and an email address. None of them belong in the agent’s own process.
• The agent’s runs, not just its logs. Foundry records every run, model call, tool call and approval. The people running the agent need to see them without opening its API to the internet.

Every team building agents solves each of these, one at a time. Kuiper solves them once.

What Kuiper does with a Foundry folder.

Kuiper knows Foundry. When it finds a foundry.config.ts or a glove-foundry dependency, it builds the app with Node 22 and your package manager, starts it with glove foundry start, and gives it:

• an HTTPS address, and your own domain if you want one;
• a disk at /data that stays across restarts and deploys;
• exactly one running copy, replaced on deploy rather than doubled;
• the model gateway, browsers, sandboxes and an inbox, reached with a key the unit gets on its own;
• an Inspect card that reads the agent’s runs, conversations and approvals through the machine it runs on.

From glove foundry dev to a live address.

Three changes to the app, then a handful of commands.

Keep state on the disk. Foundry’s default data adapter lives in memory. Point it at /data, and keep the conversation store there too:

import { defineApplication, FileFoundryDataAdapter } from 'glove-foundry';

export default defineApplication({
  name: 'concierge',
  data: new FileFoundryDataAdapter({ file: '/data/foundry.json' }),
  requestAuthorization: { /* next step */ },
});

Add an authorizer. Foundry refuses to listen on a public address without one, so its inspector and API are never open by accident. The docs have one that takes a bearer token from API clients and a login from browsers.

Send model calls through the gateway. Your provider keys stay in Kuiper, and every call is recorded with its tokens and cost:

import { Kuiper } from '@kuiper-sh/sdk';
import { createAdapter } from 'glove-core/models/providers';

const kuiper = new Kuiper(); // reads KUIPER_GATEWAY_KEY
const model = createAdapter({
  provider: 'anthropic',
  model: 'claude-sonnet-5-5',
  ...kuiper.models.glove('anthropic'),
});

Then deploy:

$ kuiper projects create concierge
$ kuiper use concierge
$ kuiper providers add anthropic --key -
$ kuiper units create concierge
$ kuiper secrets set FOUNDRY_TOKEN=-
$ kuiper env set -u concierge 'FOUNDRY_TOKEN=${{secrets.FOUNDRY_TOKEN}}'
$ kuiper env set -u concierge 'KUIPER_GATEWAY_KEY=${{models.API_KEY}}'
$ kuiper deploy --source . -u concierge --wait

The CLI uploads the folder, streams the build and prints each step of the rollout until the deployment is live. kuiper logs -u concierge -f follows the output, and the unit’s page shows its runs.

Where it’s still rough.

glove-execution, the Glove package that gives an agent execute_browser and execute_sandbox, drives browsers and sandboxes that a Station hosts. It has no adapter for Kuiper’s gateway yet. So today a coding agent on Kuiper either runs Station’s container sandboxes on its own unit, through a Docker socket Kuiper serves, or calls Kuiper’s sandboxes from tools it defines itself. Both work. A direct adapter would make it one line.

Where to go next.

• Glove on KuiperWhich Kuiper service backs each part of a Glove agent, and the steps for four shapes of agent.
• First principlesThe parts every harness is made of, and how Glove, Foundry and Kuiper stack.
• The primitives mapWhat already exists for each part, before you build it yourself.
• Put it in productionOne agent, from a laptop to Kuiper, step by step.
• Example: an email agentA unit, a mailbox, its webhook, variables and models, put together.