The workflow is no longer the product

For a decade, software asked us to draw the workflow before anyone could do the work. Glove Foundry starts from a different premise: define capable agents, give them a world, and let the route emerge from the user's intent.

We built Glove as a set of faculties. Models and tools. Rendered interfaces. Memory and inboxes. Voice and images. A mesh. A working environment in which an agent can write code, make a document, inspect the result, and try again. The pieces were useful on their own, but building a complete agent product still required every team to invent the same missing layer: discovery, composition, runtime identity, installation, event handling, scheduling, persistence, observability, and a place to see what was actually happening.

Glove Foundry is that layer. It is a file-routed, Effect-native application framework for agent systems. If Glove is the set of organs, Foundry is the body that gives them a life together.

Agents needed an application framework

Next.js did not become useful by inventing buttons. It made routing, rendering, loading, bundling, development, and deployment feel like parts of one system. Agent development has reached the same moment. A model loop is not an application framework. A tracing dashboard is not an application framework. A graph of functions is not an application framework.

Foundry gives agent products a conventional shape: agents/ is the route tree; agent.ts describes the possible agent; colocated files define the capabilities that change with it. The development server discovers those files, generates route types, assembles instances, starts the runtime, and exposes the inspection workbench.

export default defineAgent({
  description: "Turns strategy into a reviewable brand world",
  model: (_agent, ctx) => modelFor(ctx.message, ctx.agentInstance),
  tools: (_agent, ctx) => toolsFor(ctx.installations, ctx.message),
  memory: (_agent, ctx) => memoryFor(ctx.workspaceId, ctx.message),
  workingEnvironment: (_agent, ctx) =>
    ctx.messageText.includes("campaign") ? creativeWorkspace : undefined,
  systemPrompt: (_agent, ctx) =>
    creativeDirection(ctx.message, ctx.history, ctx.agentInstance.context),
});

Notice what is absent: no request input schema, no declared response shape, no station signal, no hard-coded instance. defineAgent defines a data structure. The runtime owns requests and results. The data layer owns instances and conversations. Every major capability can be assembled lazily from the current message.

The definition is not the agent

This distinction is the center of Foundry. A definition is code: what this kind of agent may use and how its parts can resolve. Its ID comes from the file. An instance is data: which applications were installed, which account metadata is attached, which playbooks and schedules are active, which workspace it belongs to, and what context makes it this particular agent.

A frontend can provision an agent, install a support application, subscribe it to two inbound events, give it a brand workspace, and change all of that later. No source file is rewritten. On the next run, Foundry loads the instance record, imports the current definition, and assembles the agent again.

The workflow is no longer the product

Most workflow software begins with the boxes and arrows. A person predicts the states, writes the branches, chooses which function follows which, and turns a messy human intention into a rigid executable diagram. That is valuable when the route is known and the cost of variation is high. It is also a strange default for work whose defining property is that the route is not known yet.

Ask for a launch campaign. One request may need research, positioning, three creative territories, image generation, a critical review, a deck, and a phone briefing. Another may already have the research and need only retail adaptations. Encoding both as the same graph either wastes work or grows a forest of branches.

In Foundry, the stable things are the capabilities and the contracts. The lead understands the intention, opens the work, provisions specialists, creates conversations, hands off artifacts through the workspace, and schedules a review. The agents can imagine the workflow and then build the artifacts that make the workflow real. The run is observable without requiring the path to have been drawn in advance.

The user describes the outcome. The system invents the work. The artifacts are not exhaust from a workflow; they are the material through which agents collaborate.

Applications make agents reachable

Applications are installed on instances, not globally baked into definitions. Each app can own several inbound and outbound transmissions. Inbound transmissions authenticate, normalize, classify, and predicate external events. Outbound transmissions become tools only after installation and account resolution.

Playbooks sit between the two as serializable runtime data. They say which classified event matters, how to merge it into a conversation, what directive the agent should follow, and where an answer may go. A playbook subscription can even provision one or many subscribed agents when an event arrives and no instance exists yet.

Credentials remain outside Foundry. You decide how they are acquired, stored, selected, scoped, and refreshed. Foundry asks your adapter for the capability a run is allowed to use. It never turns a framework database into a secret vault by accident.

Glove gives the workforce a world

This release is powerful because Foundry does not stop at orchestration. Every native Glove surface can be mounted through the same composition model:

• Memory and inboxes load for the current instance and message, rather than becoming global static configuration.
• Working environments give agents a VFS, scripts, renderers, OCR, documents, spreadsheets, slides, images, audio, video, and artifact export.
• REPLs expose a small request-specific function catalog instead of flooding every prompt with every tool.
• Mesh, subagents, and typed calls support durable peers, focused specialists, and layered S2S or S2V systems.
• Conversations, shared inboxes, tasks, and workspaces make multi-agent work a data model, not copied prompt text.
• Schedules, sleep, and background work let an agent leave the turn, wake later, update or cancel future work, and reconvene a result.
• Voice, avatars, and image generation turn the same workforce into something a user can call and something that can make and review media.

Why not LangGraph and LangSmith?

LangGraph is serious infrastructure. Its own documentation describes the core model as state, nodes, and edges, and distinguishes fixed workflows from more autonomous agents in its workflow and agent guide. If the graph is the artifact you want to design, that is a clear and capable abstraction.

Foundry makes a different bet: the durable artifact is the agent application, not the graph. Runtime installations, persisted instances, event subscriptions, conversations, workspaces, schedules, and message-aware assembly are first-class. For products where users dynamically configure agent workforces—and where the correct workflow must emerge from intent—that is the better primitive.

LangSmith is a broad observability and evaluation platform. Its tracing quickstart describes capturing application traces and viewing them in a separate service; its evaluation product supports rich offline and online programs. Foundry is not pretending those evaluation features do not matter. Its advantage is that inspection is native to the framework's runtime model: instances, conversations, passes, transmissions, schedules, handoffs, and artifacts are already the things being run, so the workbench does not need to infer an agent system from generic spans after the fact.

Why Effect

The authoring surface should feel like ordinary TypeScript. The runtime should not behave like ordinary promise soup. Foundry uses Effect for typed failures, scoped services, interruption, retries, concurrency, resource safety, and dependency layers. When provider pressure interrupts a pass, when a connection drops, or when a scheduled run is cancelled, those are explicit state transitions with policies and events—not hopeful try/catch blocks spread across the product.

The runtime can explain itself

The inspector follows one correlation line from the inbound event or user message to the final artifact. It shows which agents are active, waiting, sleeping, retrying, or done; which messages and files passed between them; which model pass or tool is running; and which outbound transmission delivered the result.

It shows work intent and safe progress notes, not private hidden reasoning. The product UI can subscribe to the same events and present a simpler campaign view, while the Foundry workbench remains available when a developer needs the whole machine.

Begin with a folder

npx glove-foundry init my-agent-system
cd my-agent-system
pnpm install
pnpm dev

The result is a codebase, not a hosted wizard you can never leave. Read the Foundry handbook, run the reference application, replace the memory adapters with your own durable ones, and make the agent system your product needs—not the graph somebody else expected.