What is a toolsystem agent?
Chat agents operate conversations. Toolsystem agents operate toolsystems.
A toolsystem agent is an AI whose job is to operate your systems correctly, on behalf of other AIs. It sits between the AI that wants something done and the systems where the work actually happens.
Different from…
… a chat agent
A chat agent talks to a person. A toolsystem agent talks to other agents and operates systems.
… an MCP server
An MCP server exposes tools. A toolsystem agent decides how to use them, against a domain contract, in one compiled program.
… an API gateway
A gateway makes tools reachable. A toolsystem agent makes them operable — correctly, by an AI that doesn't know your rules.
An LLM with full tool access and no operational knowledge is just a faster way to break things. Toolsystem agents hold the knowledge.
How Nexus works
Nexus is a toolsystem agent (powered by Claude) that operates your toolsystems on behalf of other agents. Any AI — chatbot, voice agent, MCP client, orchestrator — drives Nexus through conversation; Nexus drives the tools through code, against domain contracts, in a sandbox.
An agent.
Not middleware, not a gateway, not a plug-in. Nexus reasons about your domain before it acts.
Between the upstream AI and your toolsystems.
Conversation in. Programs out. Conclusions back.
Correct operation.
Your domain contracts govern every call. A forbidden operation is refused at the reasoning layer, before any code is written.
Any agentic flow.
Slack bots, voice agents, ChatGPT, Claude, MCP clients, orchestrators — all through conversation. Nexus speaks the same language to all of them.
Why Nexus operates systems correctly
Domain contracts, compiled in.
Your rules, your sequences, your access boundaries live as typed domain contracts loaded into the Runtime at startup. Not retrieved at query time, not stuffed into a prompt. Present on every call. A forbidden operation is refused before any code is written.
The LLM writes a program, not a sequence of tool calls.
Most agents pick tools one at a time, reasoning between each call, drifting between each step. Nexus compiles the upstream intent into a single program and executes it in one shot. The upstream AI sees a conclusion, not a transcript.
Sandbox close to your data.
Execution happens in an isolated VM with hard caps, fresh context per turn, and no path out except the ones your contract permits. Your data does not enter the LLM's context window.
Profiles, not permissions.
Every caller — a person, a voice line, an orchestrator — operates through a profile. The profile defines what they can ask Nexus to do. The contract defines what Nexus can do at all. Two gates, both structural.
The architecture, the business case, the operation
The architectural read.
Two-layer agent design, domain contracts, isolated-VM sandbox, runtime model, integration paths. The full technical brief releases alongside our first POCs. Until then, we would rather walk through the architecture with you directly.
Talk to us about the engineering view For enterpriseOne agent, any interface, your systems operated correctly.
For founders, CTOs, and enterprise buyers evaluating AI tools and hitting the same wall every time — capable AI that does not know how your systems should be operated. The detailed enterprise brief releases alongside our first POCs.
Talk to us about the enterprise view For MSPsThe AI layer that knows your stack.
For MSP founders and operations leads whose teams carry the operational knowledge — and need AI that can lift the load without breaking things. The detailed MSP brief releases alongside our first POCs.
Talk to us about the MSP viewHow an integration works
Four stages. From your system documentation to a toolsystem agent operating those systems correctly, governed by a contract you can audit.
-
Ingest and process system documentation
What goes in: OpenAPI specs, function signatures, tool specs, internal documentation — whatever describes the operations you want Nexus to understand and interact with.
-
Produce the domain contract
The output of this stage is the domain contract — a typed model of your operations that Nexus reasons against. Entity lifecycles. State transitions. What's permitted. What's forbidden. What sequences are valid. The exceptions. The rules in your docs, plus the rules in your team's heads.
This is what makes correct operation structural rather than aspirational. Nexus reasons inside the contract before any code is written. A forbidden operation is refused at the reasoning layer. Two operations that look similar but have different rules don't get confused, because the contract makes the distinction explicit. The contract is auditable — you can read it, change it, version it.
-
Runtime deployed against your systems
The runtime — the agentic execution engine — comes up with the contract loaded. It exposes Nexus's three interfaces (Slack, HTTP, MCP) and accepts intent from upstream AIs through any of them. When intent arrives, Nexus reasons inside the contract, compiles a program that satisfies the intent within the rules, and executes it against your actual systems.
-
Your team starts using it
Through whichever interface fits: Slack bot, HTTP from existing tools, MCP from Claude or other agents. Real operations on real systems, governed by the contract. Any AI tool your team uses reaches the same runtime.
Same four stages for every toolset Nexus operates. The process repeats; the coverage grows.
Start a conversation
The fastest path to seeing whether Nexus fits your operation is a 30-minute conversation. Bring one system you want operated correctly. We will tell you, honestly, whether Nexus is the right tool, whether the timing makes sense, and what a first POC would look like.
Talk to us →