Introducing M-Foundry: An Agentic Workbench for the Supply Chain

In my welcome post I promised a first project: "a new, extendable, multi-agent and multi-model harness focused on monitoring and exploring business processes." This is that project. I've been building it for a while now, it has a name — M-Foundry — and it's far enough along that I can start writing about it properly.

This post is the overview: what M-Foundry is for, what it does, and a first look under the hood. It's the opening post of a series of five — the later posts dig into each of the major pieces in real technical detail. If you'd rather skip the architecture, the first two sections will give you the full picture; if you're here for the engineering, the plumbing section and the posts that follow are for you. This is a personal project, if there is real intrest in it I will share it, maybe share the source.

The Objective

Watch a supply chain analyst or a continuous improvement engineer work for a day and you'll see the same loop over and over: pull data out of one system or more systems, shape it in a spreadsheet or a SQL client, chase down an exception, or perhaps an improvement opportunity, write up what you found, push the result into a ticket or a report, repeat. The knowledge work is real — deciding what to look at and what it means — but it's wrapped in an enormous amount of mechanical fetching, shaping, and shuttling.

Generative AI obviously has something to offer here, but I don't believe the answer is a chatbot in a browser tab. A general-purpose chat assistant can't see your data, can't touch your systems, and forces every piece of context through copy-and-paste. And for a lot of supply chain work there's a harder constraint underneath: the data may be sensitive, and shipping it to a cloud API might "need a conversation with security".

M-Foundry is my answer: an agentic workbench for the analyst. Think of a tool similar to claude corwork but knows more about the enterprise applications A small set of design principles drives everything in it:

• Assist the analyst doing their job. The unit of value isn't a clever answer, it's finished work: a query written and run, a file produced, an exception investigated, a business case for an improvement built, a ticket updated. Agents get real tools, not just a text box.
• Your choice of model — local or cloud, per agent. A model is a configuration setting, not an architectural commitment. Sensitive work can run entirely on a local model on your own hardware; heavyweight reasoning can go to a frontier cloud model. You can mix both in the same conversation.
• Connect to the analyst's real resources. Files, spreadsheets, documents, databases, and enterprise systems — the agent operates where the work already lives.
• Transparent and owned. M-Foundry is a thin harness I fully understand and control, not a black-box platform. Every tool call, every model decision, and every stopping condition is visible and logged. When AI acts on business systems, that's not a nice-to-have.

The target user shapes all of this. An analyst shouldn't have to become a prompt engineer or a Python developer to benefit — but the organization's engineers should be able to extend the system freely. That tension, as you'll see, is resolved with configuration.

The Requirements

Here are the main features, briefly. Each of these gets much deeper treatment later in the series.

Pick your model, per agent. Models are defined once, centrally, and agents reference them by name. Today my registry holds a local Gemma running under LM Studio, a local 35B mixture-of-experts model that handles tool calling cleanly, and Claude Opus in the cloud — and switching an agent between them is a one-line change to the agent setting. Any OpenAI-compatible endpoint works, so vLLM or another serving stack slots in the same way.

An agent is a config file. Every specialist agent — its model, system prompt, tools, knowledge sources, context policy, and guardrails — is defined entirely in one YAML file. There is no per-agent code in the engine at all, so building a "warehouse throughput analyst" or a "receiving exceptions investigator" is a configuration exercise, and a form-based editor in the control console means you don't even have to hand-write the YAML.

Real tools: local actions plus enterprise connectors. Agents get local tools for the formats analysts actually use — reading and writing markdown, CSV, SQL, xlsx, and docx, and reading PDFs — plus MCP (Model Context Protocol) connectors to external systems. Every tool is granted per agent against an allowlist enforced by the engine, so an agent can only ever touch what it was explicitly given.

Projects: a real workspace. Work is scoped into projects — server-side folders that hold the chats, files, and automations for one initiative. You drag a spreadsheet into the chat, the file lands in the project, and the agent reads it, analyzes it, and writes results back as new files. It's the difference between talking about your data and working on it.

Processes: scheduled and event-driven automation. Any agent-plus-prompt can be stored as a process and fired on a schedule (cron or interval) or by an inbound webhook — and a webhook can even carry files into the project before the run starts. This is the monitoring half of the vision: overnight exception sweeps, hourly KPI snapshots, and event-triggered investigations, each with a replayable run log.

Grounded in your own knowledge. An agent can pin small, high-value reference documents — a table glossary, naming conventions, business rules — directly into its context, and can query its own private RAG (retrieval augmented generation) index over larger document sets. Knowledge is isolated per agent: the finance agent cannot read the warehouse agent's index, by design.

A human in the loop, when you want one. Any tool grant can be flagged to require approval: the agent pauses mid-task, you approve or reject from the chat (with a comment the agent actually adapts to), and — because the paused state is checkpointed to disk — the approval can arrive hours later, or after a restart. Results like charts and images can also be pinned to canvases: persistent boards where an analyst arranges outputs into something like a living dashboard.

The Plumbing

A first look at how it's built. This is a deliberate skim — every paragraph here becomes a full post later in the series.

A thin harness, deliberately. The core is a stateless orchestration loop in Python: route the message, run the chosen agent, broker its tool calls, stream the result. I evaluated the agent frameworks and chose to own this loop rather than adopt one — the parts a framework provides are exactly the parts I most want to control, because the context management and routing policy are the product. All durable state lives in a session store behind an interface, so the persistence backend can change without touching the loop.

Routing and handoffs. When a message arrives, a router decides which specialist handles it — a keyword fast-path for the obvious cases, and a cheap LLM classification call over the agents' descriptions for everything else. Agents can also hand work to each other mid-task; the harness (not the agent) validates each handoff, generates a compact brief for the receiving agent, and enforces a ceiling so two agents can never ping-pong forever.

Context is managed, never accumulated. Each agent in a session gets its own private worker with its own message window, and the harness assembles exactly what the model sees before every call: pinned knowledge first, then history under a per-agent strategy (verbatim, sliding window, or rolling summarization), with strict token accounting so nothing is ever silently truncated. Tool outputs are quarantined per agent — agent A's query results never leak into agent B's context unless the harness deliberately briefs them across. That quarantine is also the choke point for stopping prompt injection riding in on tool output.

Guardrails everywhere. A budget guard sits in front of every step: ceilings on tool calls, handoffs, total steps, and output tokens per turn, a wall-clock timeout, and loop detection that blocks an agent from repeating the identical tool call with the identical arguments. Every stop is a structured, visible event with a reason — the system never just goes quiet.

One client, many models. A provider-agnostic model client speaks to OpenAI-compatible endpoints (which covers LM Studio and friends, local or not) and to Anthropic's API, with streaming and tool calling on both paths. Finding a local model that reliably emits clean tool calls at usable speed turned out to be one of the more interesting sub-quests of this project — that story gets its own post.

Two interfaces. Everything the engine does is exposed as a typed event stream over HTTP and SSE, and two React apps consume it: a chat UI for the analyst (sessions, projects, processes, approval banners, canvases) and M-Control for the operator — start and stop the engine, watch live logs, edit agents and models with validation, and build RAG indexes. The whole stack runs from a single docker compose, with the local model server staying on the host.

Where the Series Goes Next

M-Foundry is deliberately a harness rather than a finished product — the value is in how these pieces compose against real analyst work, and that's what the rest of the series explores:

1. Local vs. cloud, per agent — why model choice should be a setting, running against LM Studio in practice, and the hunt for a local model that can actually tool-call.
2. An agent is a config file — the full agent schema, the no-code editor, and grounding agents in your own knowledge with pinned files and per-agent RAG.
3. Giving agents hands — local file tools, MCP connectors to enterprise systems, projects as workspaces, and the safety rails: allowlists, approvals, and quarantine.
4. Automation and monitoring — scheduled and webhook-driven processes, human-in-the-loop workflows, and canvases as living dashboards.

As I said in the welcome post: questions, suggestions, and criticism are all welcome — ideas rarely improve in isolation. If you're building something similar, or you're an analyst wondering whether any of this would actually help you, I'd particularly like to hear from you.

More soon.