I thought I was building a backend foundation. The pain I keep seeing is AI agents calling tools twice.
I was building a backend foundation to save time on auth, billing, webhooks, and the usual plumbing.
That path is not working for me, so I’m narrowing the focus.
The thing I keep seeing in agent workflows is simple: the same tool gets called twice. That means duplicate emails, duplicate webhook hits, duplicate writes, and extra cost.
I’m thinking about building a tiny TypeScript package that does three things:
- idempotency for tool calls
- budget limits per user
- approval gates for risky actions
It would be framework-agnostic and aimed at people using LangChainJS, Vercel AI SDK, OpenAI Agents, Mastra, or custom loops.
I’d keep the core MIT and open source.
Before I build more, I’d like blunt feedback:
- Is this a real problem for you?
- How are you handling duplicate calls or runaway actions today?
- Would you install something small for this, or keep it in-house?
This is a real problem, and I think the strongest version is not only blocking duplicate tool calls but preserving the reason in the usage trail.
For agent products, duplicate calls usually show up as three separate symptoms: user-visible side effects, hidden token/API cost, and confusing billing support questions. If the runtime can label a call as idempotency-hit, retry, fallback, approval-blocked, or duplicate-write, that becomes much more useful than a raw counter.
That is the angle we keep running into with Tokens Forge. A request ledger needs to explain not just tokens and model cost, but also why the agent spent that money: which API key/project, which route, whether a fallback fired, and whether a repeated action was blocked or charged.
The package idea is good. I would make the saved-cost / prevented-action report a first-class output, not a later dashboard.
I know a few developers and founders building AI agent workflows who've run into this. I'd be happy to ask them if they'd answer some of your questions for free.
This feels like one of those painful problems everyone patches privately instead of talking about publicly.
If it saves one duplicate refund, email blast, or bad action, the value is instantly obvious.
Yes. It’s one of those things that feels like an 'edge case' until it happens to you, and then suddenly you’re spent an afternoon digging through logs to figure out why a user got three identical emails.
If it saves even one runaway loop or a double-refund, it’s done its job. Thanks for the encouragement, it’s good to know I’m not the only one seeing this.
Exactly, a lot of “edge cases” are really expensive inevitabilities once usage grows.
The best infrastructure tools feel unnecessary right up until the day they save you hours or money.
This is a real problem — duplicate calls = silent cost leak.
But right now it reads like a technical fix, not a must-have layer.
If you want this to stick, naming matters a lot here.
“idempotency / budget limits / approvals” = dev language
It doesn’t immediately signal urgency.
This is closer to:
→ preventing runaway AI spend
→ stopping duplicate actions before they cost money
Names that hint at that land much harder, like:
“AgentGuard”
“CallShield”
“ActionGate”
“SpendLock”
“AgentFirewall”
Those instantly frame it as protection + control, not just infra.
Because what you’re really building isn’t a utility — it’s a safety layer for AI agents.
Curious — are you thinking of this as a dev tool, or as a default layer every agent stack should have?
Yeah, that’s the problem I kept running into.
I started with backend foundations, but the thing that kept showing up in agent workflows was simpler: the same tool gets called twice. That means duplicate emails, duplicate webhook hits, duplicate writes, and extra cost.
So I shipped @keelstack/guard v0.1. It wraps async actions with:
It’s framework-agnostic, MIT, and live now.
I’m curious if this is something you’d actually use, or if you handle it some other way today.
This is exactly where most agent setups quietly lose money.
Duplicate calls aren’t just infra noise. They turn into duplicate emails, duplicate writes, and cost stacking per user without anyone noticing.
Right now it still reads like a dev utility. The real shift happens if it becomes:
“You’re losing $X per week from duplicate actions. Here’s where.”
That makes it non optional instantly.
If you surface the leak, not just prevent it, this becomes a default layer in every agent stack.
Curious — are you seeing actual cost impact yet, or mostly guarding execution?
This is excellent feedback. You're right, founders might ignore 'infrastructure,' but they can't ignore 'safety.' I’m already shifting the positioning to reflect that.
To your question: I’m leaning toward this being a default layer. As agents get more autonomy, you can't just hope they don't loop; you need a hard constraint at the tool level. That’s why I just shipped it as a lightweight package (npm i @keelstack/guard). It’s designed to be a standard safety gate you drop into any production stack.
You’re on the right track — but this still risks being “good infra” instead of “must-have”.
Default layer only happens when the pain is undeniable.
Right now you’re preventing it.
But what will make this stick is exposing it:
“You lost $X this week from duplicate actions — here’s where.”
That’s what forces adoption.
Also quick push — “guard” is still generic. It doesn’t carry the cost/safety angle strongly enough, so it won’t stick in people’s heads.
If this is going to be a default layer, the name has to feel like:
this protects your money, not just your code.
What are you calling it right now publicly?
Also — are you on LinkedIn? Easier to share a few tight naming directions there. I’m Aryan Y.
Thanks for the thoughtful feedback, really appreciate it.
The package is @keelstack/guard – the KeelStack org gives it weight, but I agree "guard" alone might still feel generic. I'm open to naming ideas, though the KeelStack brand stays.
And yes, I'm on LinkedIn, you can find the link on my profile. Happy to connect and hear your thoughts there.
Would love to hear what name directions you had in mind. Also, your point about exposing the cost leak is very good. I'm already thinking about adding a simple counter or estimate of duplicates blocked / money saved.
Exactly — exposing the leak is what makes it non-optional.
Even a simple:
→ “blocked 37 duplicate actions this week”
→ “~$X saved”
starts doing the selling for you.
On naming — keeping KeelStack makes sense, but the second word should carry the cost/safety signal harder than “guard”.
Just sent you a LinkedIn request — easier to share a few sharper directions there 👍