Routecraft

Open source AI capability platform  ·  v0.7.0

One team builds it.
Every team runs it.

Routecraft is where your organisation's AI tools are built, shared, governed and run. Prove a capability on your laptop, promote it to a team harness, and every agent, editor and team can call it.

See how it worksGet startedGitHub
IThe problem

Every team is building AI tools. Alone.

A script that calls the CRM. A tool that copies a session token out of a browser. Skills that work on one laptop. Three teams, three versions of the same lookup, each on somebody's own key.

Seen across these
token pasted into a .envbrowser session scrapedone API key for everyonemodel keys in the configexpires daily, log in againno retries, no rate limita handful of tests, or nonewho called? nobody knowsone author, one laptopnothing another team can install
team-atlas-agentPython
one VM, one shared key for everyone
recruitment-agentNode
a laptop, a person's token, off on Fridays
playwright-token-extractorNode
logs in as you, copies the session cookie
python-harnessPython
its own prompts, its own model key
mcp-tools-repoTypeScript
works on one machine, nobody can install it
ops-scriptsJava
scripts in a bigger repo, run by hand
copilot-skillsMarkdown
the same GitHub skill, written four times
the one in your area
not on any list yet
the next one
being written this week
a public model API?a key in the config, nobody can tell if it is set
search index
ticketing
observability
chat
wiki
source control
graph database
data store

Same problem, a stack per team, a credential per person, and nothing another team can install.

Every team builds its own: a stack per team, a credential per person.
  • Nobody can tell a person's call from an agent's.
  • Nothing built in one team runs in another.
  • The tools that matter most are the ones nobody reviewed.

Every team wants private AI tools on its own business logic. What they lack is a platform to run them on.

IIThe platform

One runtime, every way in, the same capabilities everywhere.

A capability is proven on a laptop, promoted to the team harness, and from then on every team, editor and agent calls the same one.

Every way inpeople in their editor, any agent over MCP, the CLI, HTTP, and triggers that need nobody
one per person
Local harnesson your laptop, on your own access. Try anything first.
Team harnessalways on, on service credentials, every call on record
promote when provenremote
shared as
packages
capabilities,
skills, agents
asks you when it needs a decisionpersonal credentialsservice credentials
Your systemsas they are, where they are
CRMERPHR and payrollticketingknowledge basemail and calendarchatsource control
One runtime, every way in, the same capabilities everywhere.
01

Local harness

Build and prove a capability on your own machine, on your own access. Nothing to approve before you try it.

02

Team harness

Always on, on service credentials the platform holds and no person does. Every call carries who asked, and telemetry keeps the record.

03

Built once, shared by all

Promote a capability when it is proven. Capabilities, skills and agents ship as packages, so every other team installs it instead of building it again.

04

Every way in

Your editor, any MCP client, the CLI or plain HTTP. Or on its own, from a schedule, a webhook or an email. When it needs a decision, it asks a person.

  • One place your AI tools run
  • One record of every call
  • Nothing built twice
  • People keep the decisions
IIIBounded by design

Hands, not keys.

Agents have deleted production databases trying to do their job. On Routecraft an agent never holds a credential: it calls named capabilities, each declaring its typed input and who may call it, and each call carries who asked. The capability runs where the agent is not.

Keys
agent→
databaseemaildeploypayments

can do everything the credential can do

Hands
agent→
send_company_email
input
policy
identity
intent
look_up_record
input
policy
identity
intent

can press the buttons you built; cannot build new buttons

Keys open everything behind them. Hands only press what you built.
// One of the hands the agent can reach for.
craft()
  .id('publishBrief')
  .input(BriefInput)
  .authorize({ roles: ['editor'] })
  .from(direct())
  .transform(redactPII)
  .to(http({ url: '/feed' }))

The capability is the boundary. The agent has no other surface.

The DSL is simple enough that an LLM can write the capability for you. You review the capability, not the prompt.

Expose to an agent
IVThe path

Start on your laptop. Promote it when it works.

The first capability runs on your own machine in a minute, and the agent you already use can call it. When it earns its place, it moves to the team harness and every other team installs it.

VTwo ways in

Tools for agents. Or the harness itself.

Most teams start by giving the agents they already use a few governed tools. Some go on to run the agent itself on the platform.

01

Tools for an agent

Expose a capability over MCP and Claude, Cursor, Copilot, ChatGPT or any MCP client can call it, with auth, validation and a record of every call.

Expose a capability over MCP
02

The whole agent

Run the agent on the platform: you choose the model, the prompt and the capabilities it may reach for, and what happens to the result.

Build an agent capability
VIFrom the blog

From the field.

Tutorials, postmortems, and small notes from building Routecraft in production.

The full archive
ai-agentsorganizationsmcp

AI agents are still single-player. Your organisation isn't.

The personal-assistant wave gave every employee an agent with their own access, their own memory, and their own chat window. That model cannot serve a team. The unit of organisational AI leverage is the governed capability, not the personal agent.

7 min readby Jaco Botha, Founder, DevOptix
Read the post

Routecraft is the platform. DevOptix is the team that builds and runs it with you.

AI automation built and operated for SMBs and consultancies, by the people who build the platform.

Talk to us