First principles

An agent is a model inside a harness. A coding agent, a personal assistant, a support desk and a voice concierge look nothing alike from the outside, and they are built from the same parts. Glove gives you a primitive for each part. Learn the parts once and every harness becomes an assembly job, not a rewrite.

This page builds that picture from the bottom. First the harness: the seven parts every agent needs and how they connect. Then the system: what changes when there are many agents that act on their own time. Then production: what a system needs to stay up. Each part links to the primitives map, which lists exactly what already exists for it.

The harness

A model does one thing. It takes a list of messages and the tools it may use, and returns text, tool calls, or both. Everything else (running those tools, deciding what the model sees next time, keeping what happened, letting a person in) is the harness. Written out, every harness is this loop:

save(userMessage)
while (true) {
  const input = systemPrompt + history() + liveState()   // context
  const reply = await model(input, tools)                // loop
  save(reply)                                             // state
  if (!reply.toolCalls) return reply.text                 // surface
  for (const call of reply.toolCalls) {
    validate(call)                                        // tools
    if (needsPermission(call)) await ask(person)          // surface
    save(await run(call))                                 // workspace, team
  }
  if (tooLong(history())) compact()                       // context
}

Every line is a decision. Where does history live? What counts as live state, and does adding it break the prompt cache? How do you ask a person and wait without blocking the server? What does "run" mean when the tool is a whole other agent? Glove turns each decision into a primitive you configure instead of code you write. The seven parts are the seven questions:

Here is how they connect in glove-core, for one request. The cycle in the middle is Agent.ask: the message is saved, context is assembled from what is saved, the model asks for tools, the results are saved, and the cycle repeats until the model answers without asking for a tool.

The same parts, in different shapes

What makes harnesses different is the shape each part takes, not which parts they have. Read this table down a column and you have a design; read it across a row and you see that the primitive is the same.

The harness blueprints work through each column in full: the primitives it uses, what you write yourself, and how it deploys.

The system

A single harness answers when spoken to. A product needs more: one agent per customer, each with its own history; work that happens tomorrow; a Slack message or a webhook that wakes the right agent (or creates it); a person who approves the refund before it goes out; other software that calls the agent over HTTP. These are five more questions, and Glove Foundry answers them:

Foundry keeps one rule that explains most of its design. Definitions are code, instances are data. An agent definition (agents/support/agent.ts) says what an agent of that kind can assemble, and every field may be a function of the instance, the conversation and the incoming message. An instance is a persisted record: its id, its context, the capabilities installed on it, its playbooks. Every run reloads the instance and assembles a fresh Glove harness from the definition, in its own process. So a customer's agent can gain a tool by installing it, with no deploy.

Production

A system that works on your laptop still has to run somewhere. It needs to stay up and restart cleanly, and its state has to survive a redeploy. It needs keys for model providers, browsers and sandboxes it can trust with untrusted pages and code, and an email address. Someone has to see what it did last night and what that cost. Kuiper is a deployment platform built for exactly this: it detects a Foundry folder and deploys it with no Dockerfile, the way Vercel deploys a Next.js app.

The rules the primitives follow

Glove's packages were written to a handful of rules. Knowing them lets you guess an API before you look it up, and tells you where your own code belongs.

1. The model reaches everything through tools. A subagent is a tool (glove_invoke_subagent). An MCP server's operations become tools. A browser is a tool that runs a script (execute_browser). In Foundry, an outbound Slack reply is a tool generated from a transmission. If you can describe it as a tool, every other primitive (permissions, approvals, summaries, tracing) already applies to it.
2. Every boundary is an adapter. Models, stores, display managers, subscribers, memory stores, mesh transports, filesystem backends, sandbox backends and Foundry's data layer are interfaces. Glove ships a reference implementation of each; production swaps in yours without touching agent code.
3. Capabilities mount; they don't wrap. Packages attach to an agent you already built (mountMcp(glove, …), useFormRunner(glove, …), mountBrowser(glove, …)) and never replace its model or loop. So they compose: a voice agent with memory, a sandbox and an MCP server is four mounts on one Glove.
4. Live state goes at the tail, not in the prompt. The system prompt and saved history are a stable prefix, which providers can cache. Current state (the open form, the goal checklist, pinned facts, the latest screenshot) arrives through context providers just before each model call and is never saved to history.
5. Work happens in files and code, not in context. Large data lives in a virtual filesystem or a REPL binding; the model writes a program that reads, filters and computes, and only the answer comes back. That is how one tool replaces fifty and how a 40 MB spreadsheet never enters the window.
6. Asking a person is a primitive. In an app, pushAndWait suspends a tool until the user answers. In Foundry, a permission-gated tool becomes an expiring approval record anyone with access can resolve. Neither needs a pause/resume protocol of your own.
7. Credentials never reach the model. Foundry stores account references, not secrets; adapters you own resolve them at call time. On Kuiper, provider keys stay at the gateway and units get a scoped gateway key.

Where to go next