kitted
Sign inStart building
Sign in
Use cases

One request, followed all the way down.

Simple to ask, sensitive to execute. Here is the same request seen from the assistant, from the tool that ran, and from the system that changed.

Start buildingFollow the request

“Check our fulfillment system for the longest-waiting order stuck in packing.

If its shipping label failed, move it to manual review.”

Layer 1 · The AI client

The request starts where the employee already works.

Layer 2 · Your tools layer

Kitted runs the handler and records the call.

Packing operationsRunsTest run
Run
TookStarted
update_packing_statusadad920e
ClaudeforKonrad
Queuedjust now
update_packing_statuseec12717
ChatGPTforAAlice
0.9s12m ago
update_packing_status5b7c1d43
Bedrock agentforMMarcus
1.3s1h ago
update_packing_status0a94f8e2
ClaudeforAAlice
1.1s3h ago
update_packing_statusc31e07ab
ChatGPTforKonrad
1.5sYesterday
update_packing_status8d2b64f0
Bedrock agentforMMarcus
0.8sYesterday
Packing operationsRuns
Run
update_packing_statusClaudeforKonrad
update_packing_statusChatGPTforAAlice
update_packing_statusBedrock agentforMMarcus
update_packing_statusClaudeforAAlice
update_packing_statusChatGPTforKonrad
update_packing_statusBedrock agentforMMarcus
Layer 3 · Your systems of record

The order moves, in the system that already owns it.

Where the work happened

One example.
The same three layers every time.

The assistant decided what to call. Kitted decided what that call was allowed to do. Your system of record did the work, as it already does for everything else.

Layer 1AI clients & agent platformsEvery platform here can build tools. None of them share one.
ClaudeChatGPTAgentforceMicrosoft FoundryGemini EnterpriseBedrock AgentCoreCrewAILangSmithElevenLabsand whatever's next
Over MCP or REST APIOne tool definition, reachable from every client above and from your own services.
Layer 2Your tools layerWhere your tools are built, hosted and served.
kitted
Over your own APIsKitted calls each system directly, with credentials you control.
Layer 3Your systems of recordStable, and already yours.
CRM & supportDatabasesInternal APIsDocs & storage
  1. 01The AI client

    Claude, ChatGPT, an internal agent, or a cron job with no chat at all. The client discovers the tool over MCP and calls it with typed arguments.

  2. 02Your tools layer

    A fresh sandbox, the workspace's credentials injected at run time, and a run record that keeps both the agent that called and the person behind the request.

  3. 03Your systems of record

    The WMS, the ERP, the CRM. Kitted holds no copy of your data and reaches only the hosts that tool was granted.

Three jobs, one platform

Automate it.
Connect it. Govern it.

Teams arrive with one of these three. Most of them stay for all three, because it is the same tool and the same run record either way.

Automate

The runbook step nobody wants to own.

The check your team runs by hand every morning becomes one tool with a typed input, called by whoever needs it and by the schedule that needs it at 6am.

Connect

One integration, not one per agent platform.

You already wrote the client for the WMS. Wrap it once and it answers over MCP and HTTP, so a second agent platform costs you a grant instead of a rewrite.

Govern

The answer IT asks for before it says yes.

Which tools exist, what each one can reach, who called it and when. One catalog instead of a survey of everyone's laptop.

FAQ

Questions behind the examples.

The same answers whether the call starts in an assistant, a scheduled job, or one of your own services.

Does every request have to start in an AI assistant?

No. The same deployed tool is available over MCP and a plain HTTP endpoint. Claude, ChatGPT, a scheduled job, an internal agent, or one of your own services can all reach the same execution path, with grants applied to each caller.

Do we rebuild the integration for every assistant?

No. Build the tool once. Kitted serves its live contract over MCP, HTTP, and OpenAPI, while grants decide which tools each user, client, or service can discover and call.

Can a tool write to production, or only read from it?

Either. The tool contract marks an action as read or write and can require approval before a write runs. Grants control who can call it; declared credentials, connections, and egress policy control what it can reach. Keeping sensitive actions in separate tools makes each boundary easier to review and revoke.

What happens when a tool runs?

Kitted creates a fresh sandbox for that invocation, injects only the declared configuration and credentials, captures its logs and egress, then destroys the sandbox. The run records the exact build, outcome, timings, client, and person behind the request.

Do we have to move data out of our system of record?

No. Your WMS, ERP, CRM, or other system remains the system of record; the tool calls the API or client you already use. Kitted keeps the run metadata needed for audit and debugging, with payload capture and retention controlled by workspace policy, rather than becoming a second operational database.

Can we take the tool code somewhere else?

Yes. Source is always downloadable, and each capability is an ordinary Node or Python project with dependencies declared in package.json and a lockfile, or in requirements.txt or pyproject.toml. Supply the same environment variables and run it on your laptop, in CI, or on infrastructure you operate. The code imports no proprietary Kitted runtime.

Start with the boring one

Bring one request
your team keeps making.

The tool behind it is usually a hundred lines against a system you already have a client for. The rest is what Kitted is for.

Start with the integration you already maintain.

Start building