Every time someone sees Nimblesite for the first time, they eventually ask the same question:
"Wait — you return
tool_callsto my app and I run them? Why not just run them for me?"
The answer is the single most important design decision in the platform, so it's worth a full post.
The short answer
Tools touch your data, your APIs, and your secrets. We don't want any of those. You don't want us to have them. The agent decides what to call; your app runs it in your own trust boundary.
The long answer
When you wire a tool to an agent, three things are true:
- The tool needs credentials — to a database, an API, a filesystem, a third-party service. Those credentials belong to you.
- The tool has side effects — it sends emails, writes files, charges cards, updates records. Those side effects happen in your product.
- The tool can fail, rate-limit, or misbehave — in ways that are specific to your infrastructure, your quotas, your SLAs.
If Nimblesite executed your tools on your behalf, three things would become our problem that shouldn't be:
1. We would need your credentials
For send_email, we'd need your SMTP password. For update_crm, your Salesforce token. For query_database, your database URL. Multiply that by every customer, every tool, every integration.
Not just "we'd need them" — we'd need them stored somewhere, rotated when yours change, scoped per tenant, audited. That's a secrets-management product and we're not building one.
And your security team is going to ask, quite reasonably, why a third party is holding your production credentials. You will not have a good answer.
2. We would become responsible for the side effects
If an LLM hallucinates a tool call that sends 50,000 emails because it mis-parsed "send the email" as "send emails," whose fault is that?
Today: yours, because you wrote the code that blasted emails without rate-limiting.
If we executed tools: partly ours, because we dispatched a call on your behalf without understanding your business constraints.
We would much rather the agent say "please call send_email" and your app say "no, not 50,000 at once". That's a boring, solved problem in your app. It's an unsolved problem in a shared agent runtime.
3. We would become a framework
The moment we execute tools, we need:
- A way to define tools
- A way to package and deploy them
- A way to sandbox them from each other
- A way to give them network access
- A way to give them filesystem access
- A way to handle their timeouts
- A way to version them
- A way to audit them
Congratulations, we just built AWS Lambda, except worse. Now you have to learn it. Now you have to pay for it. Now your tools live in two places and you can only run them through us.
That's the opposite of what we're trying to do.
The correct architecture
Your tools already exist. They're functions in your backend. They handle auth, logging, rate limiting, and errors the way you want them handled. They run in your language, your runtime, your trust boundary.
Nimblesite's job is to tell your app which tool the agent wants to call and with what arguments. Your app runs it. You post the result back. The agent picks up where it left off.
┌──────────────┐ ┌──────────────┐
│ Your app │ tool_calls ────► │ Your tool │
│ │ │ runtime │
│ │ ◄──── result │ │
└──────┬───────┘ └──────────────┘
│
│ conversation_id, results
▼
┌──────────────┐
│ Nimblesite │
│ (the loop) │
└──────────────┘
The agent platform decides what. Your app decides how. Neither side has to do the other's job.
The rule of thumb
If a design decision would require us to hold your secrets, execute your code, or be on the hook for your side effects — we don't do it. Not as a v1 limitation. Not as a roadmap item. By design.
That's why Nimblesite stays small. That's why integrating it takes an afternoon instead of a quarter. And that's why your security team will sign off without a month-long review.
Tools are yours. Always.