Glove Foundry
Foundry is the application framework for Glove agents. You write each agent as a TypeScript file; Foundry turns the folder into a running service with persisted agents, conversations, a run queue, an HTTP and OpenAI-compatible API, schedules, inbound integrations, approvals and an inspector.
Foundry builds on Glove; it does not replace it. Every agent Foundry runs is a normal glove-core agent with normal tools. Any Glove package — memory, MCP, REPLs, voice, image — mounts the same way inside Foundry as outside it.
What you get out of the box
| You need | Foundry gives you | Start with |
|---|---|---|
| Define agents | One file per agent; the path is its id. Typed route map generated on every dev start. | defineAgent, .foundry/routes.d.ts |
| Many agents from one definition | Persisted instances with their own context, workspace, installations and playbooks. | createAgent, defineAgentInstance |
| Per-message behaviour | Every field can be a function of the instance, conversation and the new message. | FoundryResolver, AgentAssemblyContext |
| Capabilities per customer | Shared tools, apps and MCP servers mount only on instances that install them, with typed config. | defineSharedTool, defineApp, defineMcp, install() |
| Threads | Any number of durable conversations per instance, with exact transcripts. | createConversation, conversationTranscript |
| Call agents from code | A typed client with run handles you can wait on, cancel, steer and stream. | createFoundryClient, FoundryRunHandle |
| Call agents from anything | OpenAI-compatible Chat Completions and Responses endpoints, plus an async run API. | /v1/chat/completions, /v1/responses, /v1/runs |
| Future and recurring work | Cron, interval and one-shot schedules; sleep that resumes the same conversation; spawn. | defineSchedule, glove_foundry_schedule, glove_foundry_sleep |
| Events from the outside world | Typed inbound/outbound transports, playbooks, idempotent delivery and auto-provisioned agents. | defineTransmission, composePlaybook |
| Human sign-off | Permission-gated tools pause the run on an expiring approval record. | requiresPermission, resolveApproval |
| Redirect running work | Interrupt-and-restart steering in the same conversation, with lineage. | handle.steer(), /v1/runs/:id/steer |
| Files, code and artifacts | A persistent VFS, JavaScript/Python/Lisp REPLs and document/media adapters. | defineWorkingEnvironment, defineRepl |
| Browsers and sandboxes | Mounted browser sessions and persistent coding containers on one managed Station. | mountBrowser, mountSandbox, stationDaemon |
| Guided conversations | Goals, facts and forms mounted as first-class lazy fields. | defineGoals, defineFacts, defineForms |
| See what happened | An inspector and WebChat at localhost:4141, and a correlated event stream. | glove foundry dev, /api/events |
| Keep state across restarts | Swappable data adapters, including a single-host file adapter. | FileFoundryDataAdapter, FoundryDataAdapter |
When to use Foundry
Use Foundry when the agent is the backend of a product:
- more than one user, tenant or team needs their own agent with its own data and capabilities;
- other services, UIs or SDKs need to call agents over HTTP;
- agents must act later — on a schedule, after a delay, or when a message or webhook arrives;
- people need to approve, redirect or audit what agents do.
If you are adding one assistant to an app you already run and you are happy to own storage and the request path, glove-core with glove-react and glove-next is smaller. You can move the same tools into Foundry later.
The mental model
Definition
agents/support/agent.ts. What an agent of this kind can assemble: model, prompt, tools, catalogue, schedules. Identity comes from the file path.
Instance
A persisted agent: id, workspace, context, installed apps/tools/MCP servers and playbooks. Created by your app, the API or the inspector.
Conversation
A durable thread owned by one instance. An instance can hold many at once; each has its own transcript.
Run
One message processed by one freshly assembled agent. Correlated with its model passes, tool calls, events and result.
What happens when a message arrives
- A message reaches an instance and conversation — from the typed client,
/api,/v1/chat/completions, a schedule, or an inbound transmission. - Foundry persists the run and queues it on its managed execution daemon, which executes it in a fresh child process.
- The job reloads the instance and conversation from the data adapter and loads the definition from its file.
- Each definition field is resolved for this run — literals as-is, functions called with the assembly context (instance, conversation, message, history, installations).
- Built-in Foundry tools, the definition's own tools, and the apps, shared tools and MCP servers this instance installed are mounted, along with memory, layers, subscribers, the working environment and REPL.
- The normal Glove agent loop runs; every model pass, tool call and custom event is recorded against the run.
- The result and transcript are stored; the inspector, event stream and any waiting client see the outcome.
Because step 3 happens on every run, editing an instance (installing an app, changing its context) takes effect on the next message — no deploy, no restart.
The smallest useful agent
import { createAdapter } from "glove-core/models/providers";
import { defineAgent } from "glove-foundry";
import { FileStore } from "../../lib/file-store.js";
export default defineAgent({
description: "A general-purpose assistant",
model: () => createAdapter({
provider: "openrouter",
model: process.env.OPENROUTER_MODEL ?? "openai/gpt-4.1-mini",
stream: true,
}),
// Where this conversation's transcript lives between messages.
store: ({ conversationId }) => FileStore.open(conversationId),
systemPrompt: "You are a precise, practical assistant.",
});Every run is a separate process. Foundry executes each message in a fresh child process, so anything held only in memory — new MemoryStore(...), in-memory memory adapters, module-level variables — starts empty on the next message. Use a store that reads and writes outside the process (both starter templates already do): the 25-line FileStore from the tutorial, the fuller FileConversationStore on the Persistence page, or your database.
Run pnpm dev, open http://127.0.0.1:4141, and choose Start a run. The tutorial takes this to a multi-tenant support agent with installed tools, schedules, approvals and an OpenAI SDK client.
What Foundry owns and what you own
| Foundry owns | You provide |
|---|---|
| Discovery, file identities, assembly, the run lifecycle and the inspector | Model provider configuration and API keys |
| Instance, conversation, playbook, schedule and installation records and contracts | A durable data adapter (file adapter included) and a durable transcript store |
| Tools generated from installed apps and outbound transmissions | Credential lookup and refresh behind opaque account references |
| The HTTP API, typed client and OpenAI-compatible endpoints | Request authorization when the server is not on loopback, TLS and network policy |
Foundry never performs OAuth, stores secrets, or picks an account for a user. It records only account metadata and an opaque accessRef that your adapter resolves. See the credential boundary.
Read by task
Build agents
What belongs in code, what belongs in data, how instances are created, updated and reconstructed, and where string ids are correct.
Read →defineAgent & assemblyEvery defineAgent field, the value-or-resolver rule, the assembly context, and configure/build/run lifecycle hooks.
Read →Tools, MCP & memoryAlways-on tools vs installable shared tools, MCP servers over HTTP or stdio, memory profiles, layers, subscribers, and typed calls.
Read →Goals, facts & formsGuided conversations, durable evidence and answers, native preparation, and live context providers.
Read →Connect & automate
Installable capability bundles, inbound and outbound transports, accounts, routes, connections, and the credential boundary.
Read →Playbooks, schedules & sleepEvent-driven playbooks, subscriptions that provision agents, cron and interval schedules, sleep, spawn and the built-in agent tools.
Read →Give agents a world
Many conversations per instance, transcripts, workspace entries, the shared inbox, tasks, and scoped environment values.
Read →Working environmentsMount a VFS, a REPL, programmatic tool calling, skills, and document or media adapters for artifact-producing agents.
Read →Browser & sandbox agentA runnable personal agent with mounted browser scripts, persistent code sandboxes and managed servers on one Station.
Read →Multi-agent systemsSubagents with least-privilege tools, typed calls, spawn, mesh, voice hosts, and coordination through shared work.
Read →Operate
The typed client, every native /api endpoint, the /v1/runs automation API, live event streams and health checks.
Read →OpenAI-compatible APIPoint any OpenAI SDK at Foundry: /v1/chat/completions and /v1/responses backed by durable instances and conversations.
Read →Approvals & steeringHuman-in-the-loop: permission-gated tools become expiring approval records; redirect active work with interrupt-and-restart steering.
Read →Inspector & WebChatThe built-in inspector, WebChat, run traces, keyboard shortcuts, the event envelope, and custom subscribers.
Read →PersistenceThe four things to persist separately — runtime data, transcripts, memory and the VFS — with file, SQLite and custom adapters.
Read →Next.js integrationAdd Foundry to an existing Next.js app: the generated layout, the typed client, route handlers and FOUNDRY_URL.
Read →Deploy & securityProduction checklist, request authorization, health checks, the managed execution daemon and scaling by role.
Read →