What is Routecraft

The problem it exists for

Your engineers are already building AI tools. An invoice chaser on one VM. A recruitment agent on a laptop. Expense approvals on a session cookie copied out of a browser. The same GitHub skill written four times by four teams. Each one was the fastest way to get something done, and each one runs on somebody's personal login, stops when that person is on holiday, and cannot be installed by the next team.

A policy memo does not fix this. Teams route around a ban. What fixes it is a place to run the tools: build on your own machine, promote what works, run it on service credentials, and let every team install it.

The platform in one picture

Read it top to bottom.

• Every way in. A person in their editor, an agent over MCP, the command line, plain HTTP. Those are the doors: how a capability is reached when someone asks. Beside them are the triggers: a schedule, a webhook, an email arriving, an event, a file landing. Those start a capability when nobody asks.
• A local harness per person. Your laptop, your own access, nothing to approve before you can try something. You build and prove a capability here.
• The team harness. Always on, on your own infrastructure, on service credentials no person holds, with access rules you control. When a capability has earned its place, you promote it here, and from then on every team calls the same one.
• Promote, remote, share. A proven capability moves from the local harness to the team harness. A local harness can reach the team harness's capabilities through a remote, so the two are one surface. Capabilities, skills and agents ship as packages, so the next team installs yours instead of writing their own.
• Inside every harness, the same runtime. Every call passes one gate in a fixed order: who is calling, what they may do, whether the input is valid, then throttling, retries, timeouts and caching. Behind the gate sit agents and skills, capabilities built from operations, adapters to the outside world, and the stores that let work and conversations survive a restart.
• When it needs a decision, it asks a person. Approve by mail or chat, and the capability continues, hours or days later, through any door.
• Your systems stay where they are. CRM, ERP, HR and payroll, ticketing, the knowledge base, mail and calendar, chat, source control, and any model provider you approve. Routecraft is the one governed way in.

Switch telemetry on and every call, through every door, is on record: who asked, which door, which capability, which system.

The words

A short glossary. Each one has its own page further in.

• Capability. The unit of everything. A TypeScript route that connects a source to a destination through typed steps, with an id, a description and an input schema that is validated on every call. A capability can be fully deterministic, or carry an agent inside it that reasons within the boundary the code sets. See Capabilities.
• Harness. A running Routecraft instance together with its capabilities, skills and agents. A local harness runs on a laptop on personal access; the team harness runs always on, on service credentials. Both run the same code. See Local harness, team harness.
• Agent. A model loop that works inside a capability with the tools you gave it, and only those. An agent can also live outside Routecraft, in Claude, Copilot, Cursor or ChatGPT, and reach your capabilities over MCP. Both are first class. See Durable agents.
• Skill. Instructions in markdown that an agent loads to do one kind of job, shipped as a package beside the capabilities it uses. See Project structure.
• Door. How a caller reaches a capability when someone asks: MCP for agents, the Agent Client Protocol for editors, the CLI, and HTTP. One capability, every door, the same checks. See Doors and triggers.
• Trigger. What starts a capability when nobody asks: a schedule, a webhook, an email, an event from another capability, a file. See Doors and triggers.
• Adapter. A connector to the outside world. A source brings data in, a destination sends it out, and some do both. See the adapter reference.
• Operation. A step inside a capability: transform, filter, enrich, split, aggregate and the rest. See Operations.
• Exchange. The message that moves through a capability: a body and headers. See The Exchange.
• Context. The runtime that loads capabilities, starts them, stops them and runs one on demand. See the CLI.

How a capability is built

Every capability has the same shape. This one is an MCP tool: an agent calls it with a name, the input is validated against the schema before any code runs, and the tool answers with a greeting.

// capabilities/greet-user.ts
import { craft, log, noop } from "@routecraft/routecraft";
import { mcp } from "@routecraft/ai";
import { z } from "zod";

const GreetInput = z.object({
  user: z.string().trim().min(1).describe("The user to greet."),
});

export default craft()
  .id("greet-user")
  .title("Greet user")
  .description("Greet a user by name")
  .input({ body: GreetInput })
  .from(mcp())
  .transform((body) => `Hello, ${body.user}!`)
  .tap(log())
  .to(noop());

Swap mcp() for http(), cron() or mail() and the same pipeline answers a request, runs on a schedule or reacts to an email. Put more than one source in .from() and one capability serves them all.

The DSL reads as a pipeline, top to bottom:

craft()
  .from(source)
  .transform(fn)
  .to(destination)

Two places to start

• An empty project. bunx create-routecraft my-project scaffolds one capability that is already an MCP tool. Connect the agent you use today and call it. Start here when you want to give an existing agent a tool. Tools for agents walks it through.
• craft-harness. A complete local harness to start from: chat, a sandboxed shell, web fetch and search, a workspace, memory, a scheduler and human approvals, each an ordinary capability under capabilities/ with its guardrails where you can read them. It serves MCP and the editor protocol from the first boot. It is a Routecraft project like any other, not a product on top: read it, keep what you need, delete the rest. Start here when you want an agent of your own. An agent of your own walks it through.

bunx create-routecraft my-agent --example https://github.com/routecraftjs/craft-harness

Hands, not keys

An agent that holds a credential can do anything that credential can do. An agent that calls a capability can do what the capability does, and nothing else.

On the team harness, the credential belongs to the capability, not to the agent and not to the person asking. A call reaches your code only past the checks the capability declares: the identity of the caller, the authorisation rules you wrote, and the input schema. The tool's declared intent, the description and schema an agent reads, steers what it asks for; the checks hold whatever it asks. The agent reaches the capability over a door and never sees the secret behind it, so there is nothing for it to copy, leak or reuse.

This is also why the local harness is safe to hand to every engineer: on a laptop a capability runs on that person's own access, and promoting it is the moment it moves onto service credentials and under the team's rules. Credentials and identity is the full model.

How it differs from what you may already use

• An integration framework such as Apache Camel. The same model: routes, exchanges, adapters, a fluent DSL. Routecraft is that model in TypeScript, with MCP, the editor protocol and agents as first-class sources and steps, so you do not need a second system for the AI side.
• An agent framework such as LangGraph. Those build the agent. Routecraft builds the tools the agent uses, and can host the agent too, as a capability with the same validation, authorisation and telemetry as every other call. Your agents in Claude, Copilot or Cursor keep working, with hands.
• The plain MCP SDK. Routecraft is an MCP server, and every tool on it already has the gates, the service credentials, the audit record, and restart-safe human approval. The other doors sit beside it on the same instance, so the tool you wrote for an agent is also an endpoint and a scheduled job.

Where most teams stand

Most teams have a prompt library and a repository of skills and agents. The jump that matters is deployed capabilities: tools that run somewhere other than a laptop, on credentials no person holds, that another team can install. That jump is what the platform is for.

Where to go next