Making Agents Usable Through a Basic API Instead of a UI
Most agent tools look fine at first, but break the moment you try to plug them into something real. The UI is usually not the real issue. The friction shows up when you want to use the agent outside the tool itself. In practice, I don’t want another dashboard. I want something I can call from a backend, a script, or an existing system without extra glue work every time.
We kept running into this while building and testing workflows. Every new use case meant wiring things again instead of reusing anything cleanly.
So we ended up exposing the agent through a simple HTTP API instead of forcing everything through a UI.
We open sourced the gateway layer we built for this here: https://github.com/agent37-platform/gateway
Now it behaves more like a service. Send a request, get a response and plug it into whatever stack you already have.
Still early but it already feels closer to how these systems should actually be used.
Curious what others think. Do you prefer working with agent UIs, or do you only trust tools that expose a clean API you can integrate yourself?
Great read!
Thank you for appreciation.
yeah, the abstraction layer itself can become the dependency if you're not careful. I baked provider-specific assumptions into my own wrapper before I caught it. Thin routing logic is the real goal.
This is interesting. I like the idea of making agents usable through an API instead of forcing everything into a chat UI.
Do you see Agent37 more as infrastructure for developers, or as something non-technical teams can also use directly?
That's a good question. Right now developers tend to see the value fastest because they're the ones integrating agents into existing systems. But the longer term goal is to make the underlying capabilities accessible to non technical teams as well without requiring them to think about the infrastructure underneath.
to answer your question: API only, always. the UI is useful for understanding what an agent can do but it's never the thing I actually want to ship. the friction you described about wiring things again for every new use case is exactly why. the interesting design question for your gateway is how you handle agent state between calls. a stateless API is easy to integrate but limits what the agent can do. a stateful one is more powerful but harder to reason about when something goes wrong
That's a great point. My instinct is that developers generally prefer having more control over state since it makes debugging and integration much easier. The challenge is finding the right balance between flexibility and simplicity without making the system feel too magical.
the question of what stops SEO farms from doing this at scale probably answers itself over time. the farms that can produce 100 articles a week at genuine quality will be the same farms that are spending so much on quality gates and human review that they're no longer farms. the economics of high-quality content haven't changed. it still costs roughly what it always did to produce something genuinely useful. AI just made the low end cheaper
I like the API-first approach. Most agent tools over-index on UI when developers just want clean APIs. Curious: do you have rate limits per agent identity, or per IP?
Appreciate that. We're still early so we're iterating on some of those platform-level controls based on how people actually use Agent37. Right now the bigger focus has been making agents easy to deploy and integrate but rate limiting is definitely something we're thinking about carefully.
AI makes our work much easier these days, and based on the description of the tool presented here, it will be very useful. Congratulations and good luck with what's to come...
I appreciate that! The goal with Agent37 is to make AI agents easier to deploy and integrate into real workflows, not just demo environments. There's still a lot to build, but feedback from builders and early users has been incredibly helpful in shaping the direction. Thanks for the encouragement!
Clear useful content
Much appreciated.
Exactly why the 'wrapper app' era is collapsing under its own weight. If your AI stack relies entirely on a black-box cloud API, you have zero control when it hallucinates, leaks data, or breaks a workflow.
The only real way to enforce human accountability is building on sovereign, local-first architectures. I spent the last few months mapping this exact problem out in the Operator's Field Manual—designing a dual-brain system where the local operator is always the hard anchor, not the model.
If you're building systems where failure isn't an option, sovereignty isn't a feature; it's the baseline.
I get the direction you’re pointing at, especially around control and failure modes. In practice though even local first setups usually still need an external layer for coordination once you start connecting multiple services or workflows. The real problem is less about where the model runs and more about how you define boundaries, accountability and observability across the whole system. How your dual brain approach handles actions that span outside the local environment?
I see your point. Honestly, it is not some crazy structural hurdle, and if I can set this up, anyone can do it. But once your agent needs to step outside your local machine to touch external APIs or live web workflows, you are dealing with a totally different beast.
The way to handle actions outside your local setup is simply to treat the external world as an untrusted zone.
Instead of letting an agent run wild, you split up the reasoning from the actual execution.
The brain core: this stays inside your local environment and does the heavy lifting, like crunching your private data and deciding what needs to happen next. It never talks directly to the outside world on its own.
The bridge layer: This is just a basic, isolated layer meant for handling outside tasks. If the core brain decides the agent needs to update a calendar or hit a third-party webhook, it sends the request here.
The real trick to keeping things accountable is putting a human gatekeeper right at that border.
Instead of full, blind automation where an agent can glitch on an external API error and loop infinitely, the local setup queues the action for a quick manual approval. A human clicks okay, the bridge layer runs the task, and only clean data is allowed back inside. The real problem is definitely system boundaries and knowing exactly what your system is doing. Isolating outside actions into simple, human-gated steps gives you complete control over what leaves your machine and what comes back in. You keep your data completely sovereign at home while still using the live web when you need it.
The UI basically stops mattering as soon as an agent touches a production workflow. What matters is the contract: a clean API, a predictable behavior and a way to understand why it decided to do something at 2am. The rest (the UI, dashboards, whatever else) is mostly onboarding and debugging, IMHO.
I mostly agree with that. Once it’s in production, the UI becomes secondary. The real system is the API contract plus observability around decisions and actions. The only place I still see UI mattering is during iteration and troubleshooting, but even that fades fast once things stabilize. Its like the core product shifts from “how you use it” to “how you trust it.”
I think a lot of agent products are accidentally building destinations instead of infrastructure. A UI is great for testing and demos, but the moment an agent becomes part of a real workflow, API access starts mattering more than the interface itself. Curious if you've noticed any patterns in how people are integrating it so far.
I’m seeing the same split. Early users treat it like a product but the ones getting real value quickly move toward embedding it into existing systems and workflows. At that point the UI is mostly just for setup or inspection. Integration patterns seem pretty simple so far either direct backend calls or wrapping it into scheduled jobs and internal tools. Are you seeing any cases where people still prefer keeping the agent as a standalone destination instead of embedding it?
but it isnt hard to do that
Yes it’s not hard technically. The harder part is usually everything around it like reliability, observability and knowing what the agent actually did once it’s running inside a real workflow. That’s where most setups start to feel less “plug and play” than they look at first.
I’ve been seeing the same pattern. UI works fine for demos but once you start thinking about actual usage, most of it moves to backend or automated flows anyway. Feels like agents are slowly becoming infrastructure pieces rather than tools people sit inside. In that case, API first design just makes more sense.
Yeah, that’s exactly what it’s starting to feel like. UI is great for discovery and setup, but real value shows up when the agent becomes something you can embed and forget inside workflows. Once that shift happens, it stops being a “tool you use” and becomes more like infrastructure you rely on in the background.
Not fully convinced agent UIs are going to stay relevant for long. Most of the real use cases I’ve seen are either scheduled tasks, backend workflows or integrations into existing products. In all of those, the UI is basically unused after setup. We’re still early in figuring out what “the right interface” for agents actually is. Would be interested to hear if anyone here has a strong case where UI is still essential.
I think UI still has a role but mostly in early setup and debugging. When you’re testing prompts or behavior, it’s useful to see what the agent is doing step by step. Also for non technical users, it helps as a control layer. But for real usage, most workflows move to backend, scheduled tasks, or integrations. After that, UI is rarely needed. Feels like UI is more for setup than actual execution in most cases.
Yeah this is the part most people only realize after things go live. Once agents are in real workflows, it’s not just about calling them, it’s about knowing why they acted and being able to trace it clearly when something goes wrong. Are you treating governance as a separate layer, or building it directly into the agent runtime?
I'd be careful treating this as a UI-versus-API decision too quickly.
The interesting question may not be how people prefer to interact with the agent.
It may be what role the agent is expected to play once it becomes part of a real workflow.
Those sound similar, but they can lead to very different conclusions about the product, the buyer, and which signals deserve confidence early on.
I wouldn't make that call casually from the current feedback.
I agree this is less about UI vs API and more about the role the agent plays in a system. Right now we’re seeing signals from how people start using it, not necessarily how it should exist long term in a workflow. Feels like the real clarity only comes once it’s running in production across a few different environments, not just early usage patterns. Curious what signals you personally would trust early on when defining that role?
Possibly.
The reason I stopped short is that I don't think the useful part is the list of signals.
I think it's the decision those signals are being used to make.
That's one of those things that can quietly shape the entire product if the wrong signal gets trusted too early.
I wouldn't try to unpack that properly in a thread.
If you're curious, drop your email and I'll put together the tighter version.
Interesting approach! Is the API public?
Strongly agree with this, and not even in the agent space specifically — I hit the same thing building a language analysis tool. The actual hard part of my backend is racing several LLM calls in parallel and handling whichever fails or times out, but none of that should leak to whatever consumes it. Once I committed to a clean API surface, the messy part (retries, fallback when a model is slow, normalizing wildly different outputs into one schema) became something I could iterate on without ever touching the consuming side.
The UI-first instinct makes sense for demos, but it quietly assumes the dashboard IS the product. The moment someone wants to embed this in an existing workflow, that assumption breaks, like you said.
One thing I'd be curious about with your gateway: how are you handling partial failures or slow responses on the API side? That's the part that always ends up leaking through "clean" interfaces for me — a 200 response that took 25 seconds doesn't feel clean from the caller's side even if the contract is simple.
I think that's where a lot of the complexity actually lives keeping the interface simple while hiding the messiness underneath. We're still iterating on that side, but my bias is that callers should have as much visibility as possible into failures and latency rather than pretending everything is fine behind a clean API. A simple contract is great but not if it hides information that users need to build reliable systems.
I agree with the API-first direction. For agents, the dashboard is usually useful for demos, but the real adoption happens when it can be called from an existing workflow without forcing the team to change how everything else works.
The tricky part is probably not the API itself, but making state, retries, permissions, and failures predictable enough that people trust it in production.
Absolutely. Getting an API working is one thing but making it predictable enough for production use is a completely different challenge. In my experience, trust comes less from capabilities and more from knowing how the system behaves when things go wrong. That's where a lot of the real engineering work ends up happening.
Strongly agree. Once agents are API-first, one thing I’d add early is cost observability per workflow. A clean API makes integration easier, but it also makes spend easier to hide because calls are happening in scripts, cron jobs, retries, background jobs, etc.
For our own AI tool work I’ve found the useful view is not just total tokens, but which workflow/model/prompt shape caused the spike. Otherwise you only notice when the bill shows up.
Tiny plug since it is directly related: I’m building TokenBar for Mac to keep token usage visible while working with LLMs: https://tokenbar.site/
That's a really good point. Once agents move into background workflows, visibility becomes a lot harder than when everything happens through a UI. I like the idea of breaking usage down by workflow and model rather than just showing aggregate token counts. In many cases, the expensive part isn't the agent itself- it's a retry loop, a prompt change or a workflow that quietly scales beyond what you expected. Will definitely be paying more attention to observability as Agent37 evolves. How are you handling costs across multiple providers/models?
Agree the UI stops mattering once an agent is in a real workflow. But going API-first quietly changes who your buyer is. A UI tool sells itself in a demo. An API tool lives or dies on time-to-first-successful-call, your buyer is now a developer who bounces if the first integration takes more than ten minutes. So the gateway README and a copy-paste example matter more than any dashboard. One thing I learned running an integration-heavy business for years: what keeps people embedded is not the API, it is never breaking the contract. The first time a silent change breaks someone's pipeline at 2am, they rip you out and do not come back. Version hard, deprecate loudly.
noice
Completely agree with the API-first approach. Once you move past the demo phase, you just want a reliable endpoint to plug into an existing stack. Out of curiosity, how are you planning to tackle complex orchestration or rate-limiting/queues when these API-driven agents start chaining multiple long-running tasks?
This resonates. The UI isn’t the problem — the “can I actually integrate this into my workflow?” question is.
A clean API also forces the right constraints: clear inputs/outputs, idempotency, retries/timeouts, and observability. Otherwise the UI hides a lot of flaky glue (auth, rate limits, context size, tool failures) until you try to productionize it.
Curious: how are you handling versioning + reproducibility?
Do you pin model/tool versions per request?
How do you log inputs/outputs safely (PII) while keeping runs debuggable?
API over UI is the right call. but it concentrates vendor dependency harder. when your agent provider gets acquired - and several have recently - you're not just swapping a URL, you're re-benchmarking every workflow that assumed consistent behavior.
That's a fair point. A clean API makes integration easier, but it doesn't eliminate dependency risk underneath. I think that's one reason abstractions and provider flexibility matter so much. The less business logic that's tied to a specific provider's behavior, the easier it is to adapt when the landscape inevitably changes.
Good point, that’s where it gets real. Auth is scoped API keys at workspace level, with permissions per agent and action. Rate limits are split between workspace level caps and per endpoint limits. Hardest part is not basic limits, it’s keeping things stable when agents start chaining calls. That’s where we’re now thinking about queues and backpressure.
queues and backpressure for chained agent calls is the right problem to be solving — that's exactly where most agent frameworks fall apart in production.
are you building the queue layer yourself or leaning on something like BullMQ or Inngest? curious what tradeoffs you're hitting at this stage..
We are looking for someone who can lend our holding company 175,000 US dollars.
We are looking for an investor who can lend our holding company 175,000 US dollars.
We are looking for an investor who can invest 175,000 US dollars in our holding company.
If you lend our holding company 175,000 US dollars, I will return your money to you as 350,000 US dollars on 30/03/2027.
If you invest 175,000 US dollars in our holding company, I will return your money to you as 350,000 US dollars on March 30, 2027.
I will return your money to you as 350,000 US dollars on March 30, 2027.
I will repay the 175,000 US dollars you lent to our holding company as a loan to you as 350,000 US dollars on March 30, 2027.
We will use the 175,000 US dollars you invested in our holding company to grow our business, and on March 30, 2027, we will return your money to you as 350,000 US dollars.
I will return the 175,000 US dollars you invested in our holding company to you as 350,000 US dollars on March 30, 2027.
You will receive your money back as 350,000 US dollars on March 30, 2027.
I will refund your money to you as 350,000 US dollars on March 30, 2027.
You will be earning twice as much in a few months.
You will have doubled your money in a few months.
So how will we increase your money?
With the 175,000 US dollars you lent to our holding company, we will establish an artificial food production company.
With the 175,000 US dollars you invested in our holding company, we will establish an artificial food production company.
With the 175,000 US dollars you invested in our holding company, we will establish an artificial food company that produces tastier, higher quality, healthier, protein-rich, and nutritious food products.
In the artificial food company we will establish, we will use the genetics of animals, vegetables, plants, and fruits to artificially produce tastier, healthier, and protein-rich food products.
We will produce a wide variety of artificial food products.
We will produce fruits, vegetables, snacks, meat products, dairy products, artificial water, beverages, and other artificial products.
Since the food products we will produce are artificial foods, we will have prevented famine.
Many countries today are experiencing famine and drought; by establishing an artificial food company, we will be able to prevent both famine and drought.
We will be able to produce more protein-rich, healthier, and tastier food products in a laboratory environment without the need for agriculture or animal husbandry.
We will produce new types of fruits and vegetables; these new types of fruits and vegetables will greatly attract people's attention.
Thanks to our artificial food project, humanity will be able to easily produce food without agriculture and animal husbandry.
As wars increase around the world, leading to increased famine, the artificial food products we will produce will be in high demand globally.
By developing systems that can produce water from the air, we will also be able to prevent water scarcity.
As our capital increases, we will open artificial food production facilities in all countries of the world. Our goal is to sell the artificial food products we produce to the whole world.
The products we will produce will be longer-lasting, and because they will be longer-lasting, we will also save money. We will produce environmentally friendly products.
Since the food products we will produce will be artificial foods, people will be able to consume the same fruits and vegetables in both summer and winter.
People will be able to consume summer fruits and vegetables at cheap prices even in winter.
We will sell the artificial food products we produce at a low price, so people will be able to buy healthier, tastier, higher-quality, and longer-lasting food products at a low price, and in this way, we will prevent global food shortages.
The products we produce will have a long shelf life; since we will be producing long-lasting food products, they will be environmentally friendly, and in this way, we will also save money.
Thanks to our artificial food project, people will now be able to consume high-quality food products at affordable prices.
How will we market the artificial food products we produce?
We will sell the artificial food products we produce internationally to the whole world.
By selling our artificial food products internationally, we will generate more profit.
We will ensure that our products are sold internationally by using 13 different methods.
We will market our product using 13 different methods.
1. Method: By making agreements with supermarkets, grocery stores, and food retailers in many countries, we will ensure that our products are sold by supermarkets and all retailers in many countries.
2. Method: As our capital increases, we will open our own markets worldwide to sell our artificial food products directly to consumers.
3. Method: We will launch a dedicated e-commerce website for our artificial food products. This platform will allow customers worldwide to purchase our products online, which will significantly boost our global sales volume.
4. Method: We will offer our artificial food products for sale on the online sales sites of many countries.
5. Method: By selling our products to wholesalers in many countries, we will enable them to sell our products to local retailers in their own countries. Thanks to the wholesalers, our products will sell even faster.
6. Method: We will implement a referral system. If people find customers for our products and help sell them, they will receive a 25% commission for each customer and thus earn income.
7. Method: We will partner with high-reach influencers across platforms like Instagram, TikTok, and YouTube to promote our products. This strategy will allow us to leverage their large audiences and significantly increase our sales.
8. Method: By utilizing advertising platforms such as YouTube Ads, Google Ads, and Facebook Ads, we will reach a global audience with our promotional videos, which will rapidly accelerate our sales growth.
9. Method: We will attract millions of customers to our product using our own advertising techniques. Thanks to our strong advertising network, our artificial food products will sell quickly.
10. Method: We will promote our artificial food products by placing posters in areas with high population density in many countries.
11. Method: We will pay news and blog sites to advertise our product, thereby making it known to a large international audience.
12. Method: We will send a promotional text about our product to millions of emails using email marketing.
13. Method: We will advertise our product internationally on television channels.
By using various advertising techniques, we will achieve significant profits within a few months, and our products will become even more popular internationally.
How much profit will we make, on average, from the artificial food products we produce?
We decided to enter the artificial food sector because it is an innovative sector; our goal is to become a pioneer in the artificial food sector.
Our products will sell very well internationally because we will be producing healthier, tastier, more nutritious, and protein-rich artificial food products.
Even if we sell 800,000 kilograms of tomatoes at 3 American dollars per kilogram in just 4 months, our earnings for those 4 months would amount to 2,400,000 American dollars.
Just selling tomatoes alone would bring us millions of dollars in revenue within 4 months.
Because we will be producing and selling not just tomatoes but also various types of artificial food products, we will generate billions of dollars in revenue within a few months.
The artificial food products we will produce will be tastier, richer in protein, and healthier, so they will be in high demand internationally and will bring us billions of dollars in revenue.
Since we will be producing new types of fruits and vegetables, it will attract a lot of interest from people and will increase our sales rate even more.
We will open our first artificial food production company in Brazil.
We will establish our first production company in Brazil because it is a country where we can both source production materials and make more sales.
How can you contact us?
For detailed information about our artificial food project, please send a message to my Telegram username or Signal contact number below. I will provide you with detailed information.
To learn how you can lend our holding company 175,000 US dollars, please send a message to my Telegram username and Signal contact number below. I will provide you with detailed information.
To learn how you can increase your money by investing 175,000 US dollars in our holding company, send a message to my Telegram username or Signal contact number below. I will provide you with detailed information.
To learn how you can invest 175,000 US dollars in our holding company and participate in our artificial food project, please send a message to my Telegram username or Signal contact number below. I will provide you with detailed information.
For more detailed information, please send a message to my Telegram username or Signal contact number below. I will provide you with detailed information.
My Telegram username:
@adenholding
Signal contact number:
+447842572711
Signal username:
adenholding.88