The NimbleBrain Platform

Most agents reach a chat window. This one reaches your billing system, your tickets, and the internal service nobody wrote an API for.

Read the docs View the source

What the architecture gets you

  • Reach every system you run

    Install a connector in a click, reach 300+ more through a gateway, or point the runtime at a server you wrote yourself.

  • Keep your data where it is

    The runtime executes inside your own infrastructure under credentials you hold, so there is nothing on our side to breach.

  • Change it without an engineer

    Skills are plain files. The person who owns a process edits it and sees the change on the next run.

What the runtime is made of

Six capabilities, one page each. Start anywhere — they are ordered the way most teams meet them, not by importance.

Security by design

Private, verifiable,
and inside your boundary.

Three promises, and none of them asks you to take our word for it.

  • Verifiable

    You do not have to trust the claim, because you can read the thing that makes it.

    • Apache 2.0

    Read it, fork it, and keep running the version you hold. The licence cannot be withdrawn from you later.

    Read the source

  • Private

    For most customers we never hold your data, because the runtime executes inside your own boundary.

    • Runs on your infrastructure, or ours if you prefer
    • Credentials sit with their owner and are never pooled
    • Any model provider, including one on your own hardware
    • Nothing is trained on your data

  • Isolated

    A session is handed one workspace. The identifier that would address a second one does not exist in that context.

    1. 1 A session opens against one workspace
    2. 2 It is handed that workspace’s tools, and no others
    3. 3 Membership is re-checked on the next run
How isolation works

Platform

Questions people ask first

Is this open source, or a product you sell?
Both, and they are the same software. The runtime is Apache 2.0 — read it, fork it, run it on your own hardware, and keep running the version you hold. We also run it for you if you would rather not operate it. What you get is identical either way; the only thing that differs is whose machine it sits on.
Which model does it use?
Whichever one you configure. The model is a setting rather than a dependency, so you can point it at Anthropic, OpenAI, Gemini, an open-weights model, or something on your own hardware — and change your mind later without touching an agent, because the skills and connectors are not tied to a provider.
How is this different from an agent framework?
A framework is a library you build with. This is a runtime you run: it holds the agents, the state, the credentials and the audit trail, and it is already wired to reach your systems over MCP. If you want to write the loop yourself, use a framework. If you want the loop to already exist and to be reviewable, use this.
What does it actually connect to?
33 connectors are installable from the built-in directory and 300+ more are reachable through a managed gateway. The number that matters is the third one: a connector here is an MCP server against a published standard, so a server you write on a Tuesday is reachable on exactly the same terms as Salesforce.
Does our data go to you?
For most customers, no — the runtime executes inside your own boundary and reaches your systems under credentials you hold, so there is nothing on our side to hold. On the managed option we operate the runtime, and your connector credentials still sit with the workspace that owns them rather than being pooled.
What does it take to get started?
Docker Compose on a laptop is enough to see it working. Production is a Helm chart on your own Kubernetes, or our managed runtime. Most teams start with one process that is already painful and already touches three systems, because that is where the difference from a chat window is obvious.

Run it yourself, or have us put it to work.

Start with discovery

Read the docs