Everyone is experimenting with AI agents. It is an exciting time, and often a frustrating one, because scripts written on a laptop rarely survive the move into company-wide deployment. David Bečvařík, CTO of Etnetera Core, decided to solve the problem his own way. Instead of looking for a ready-made tool, he built a platform for running agents.
David, there is enormous hype around agents in the community right now. At Etnetera we felt something was missing. What was the main trigger for building your own platform?
For us it was a practical problem. It didn't start with a decision to build an agent platform because that happens to be the trend. It started with agents that could do interesting things but lived somewhere on a laptop, in a local script or in a prototype. That is the exact point where the difference between an experiment and production shows up.
An experiment on a laptop is great for validating an idea. But in a company we need to know who started the agent, what data it had access to, how much it spent, what exactly it did, why it did it and how we can evidence all of that afterwards. We also need the agent to hold its place when it is waiting for someone's approval, when a service goes down or when the infrastructure restarts.
So the trigger was simple. Agents needed a home. An environment with clear boundaries, security, an audit trail and operational reliability. Without that, an agent is just an interesting demo, and the internet is full of those. We wanted something usable at a client, where regulation, security rules, budgets and accountability all exist.
In interviews you often say our platform is not a chat window. What exactly do you mean?
We see this as one of the biggest shifts in thinking. Many people still picture AI as a chat window: you type something in and it answers. That is not a production model of work. It is an interaction. Often a useful one, but still only an interaction.
We don't want a company to simply talk to a model. We want the agent to do specific work. To have a clear task, inputs, rules, approval steps, limits, connections to systems and an output that can be verified. That is a huge difference.
A chat is a one-off experience. An agentic workflow has to be repeatable, traceable and testable. That is why we define an agent as a controlled process rather than a free conversation. The model is only one component. Everything around it matters: orchestration, state, security, validation, tests, monitoring and audit.
It works much like conventional software. Nobody sensible would push code to production just because it once ran on a developer's machine. The same has to apply to agents. If they are going to do serious work, we have to treat them as software, not as a clever chatbot.
Temporal is a key element of the platform. Why does it matter so much for agents?
Temporal is a fundamental building block for us because it solves something that gets badly underestimated with agents. An agent in the real world does not run for five seconds. It often waits. For a person, for a CRM, for an approval, for an external system or for the next step in a process. And through all of that it has to keep its context.
With a simple script, everything looks fine for as long as it is running. The moment it crashes, we have a problem. We don't know exactly where it stopped, what it already did, what should be repeated and what definitely should not be. For an internal tool that is annoying. For an agent working with data, calling APIs or changing things in systems, it is serious trouble.
Temporal gives us resilience. Every step of a workflow is state-driven and recoverable. When something fails, the agent does not start again from zero. It carries on where it left off. That is the difference between "hopefully it will finish" and "we know how it will behave".
And that is exactly the difference between a prototype and a production system. An agent cannot be a magic box. It has to be part of an architecture that accounts for errors, outages, retry logic, timeouts and human approval.
Interestingly, you built the platform itself using AI agents. How does that work in practice?
It is decent dogfooding. We build a platform for agents using agents. It tells us very quickly what works only in a presentation and what holds up in real work.
Our agents have clearly defined roles. One behaves like a product person, another like an architect, another writes code, another does review. But it is not a case of telling a model to "write it somehow". That would be a route straight into chaos. We have rules, workflows, tests and clear boundaries of responsibility.
Every meaningful change has to be supported by the architecture, by tests and by an acceptable design. We push hard on E2E tests, integration tests and validation against expected behaviour. Agents are excellent at speed, but accuracy does not appear on its own. It comes from a good brief, good guardrails and fast feedback.
This matters for companies in general. AI will not rescue bad engineering. It usually exposes it very quickly instead. Without architecture, tests and clear processes, agents simply speed up the chaos. With them, agents can dramatically accelerate both development and operations.
What would you advise companies that want to deploy agents but are worried about security risks?
The first rule is simple. Don't let agents reach data, systems and keys directly. In our view that is the most common mistake. Someone takes an API key, hands it to the agent, connects a few tools and it feels done. In reality they have often opened a security hole.
We handle this through an LLM gateway and an MCP proxy. The agent never works with the real key to OpenAI, Anthropic or any other model. It gets a virtual key and every exchange goes through a controlled layer. That is where we manage budgets, limits, logging, guardrails, sensitive data detection, rules for a specific client and, where needed, validation of what leaves the organisation.
The second thing is auditability. In production it is not enough to say the model decided somehow. We need to evidence what the input was, which tool the agent used, what decision it made, where it waited for a human and what the final output was. Without that, agents cannot be taken seriously in a regulated environment.
The third is least privilege. An agent should not have access to everything just because it might come in handy. It should only reach what it needs for a specific task. The same as a person or a service in any normal architecture.
What are the next steps for the platform? Where are you heading now?
We are moving from the platform core towards repeatable use. That is the key part. We don't want to build every agent from scratch. We want a library of safe blueprints and components that can be assembled quickly into a specific solution for an internal process or a client project.
Developers and teams should not have to solve basic hygiene again every time. How to start an agent, how to cap it with a budget, how to audit its steps, how to connect tools, how to handle human approval, how to validate data and how to run the whole thing. That belongs in the platform.
At the same time we don't want to depend on a single model or a single cloud. The platform has to work with large models from OpenAI or Anthropic, and also with smaller local models where that makes sense on cost, latency or data sensitivity.
In practical terms, the goal is simple. A team arrives, takes a safe blueprint, adjusts the domain logic, deploys the agent and knows it is operating within the guardrails. Securely, auditably and at scale.
David, thank you for the candid insight. Looking ahead, where will we be with these technologies in a year?
We think that in a year we will be smiling at what we consider advanced today. Not because it is wrong, but because the pace of development is extreme. A lot of what we glue together by hand now will be a standard part of development and operations platforms.
We also don't think the future lies in having more chat windows. We see that as a dead end. Agents will sit further in the background, connected to processes, systems and data. People will set the goal, check the critical steps and handle the exceptions. Agents will do the routine work.
One thing will not change though. It will still be engineering. AI is not magic. It is software, data, processes, security, observability and accountability. Underestimate that and you end up with expensive experiments. Build it well and you gain enormous leverage for development, operations and the business.
That is the most interesting part of this whole AI wave for us. Not that a model can produce a nice answer, but that we can build systems taking over parts of the work, systems that stay controllable and can be put into environments where the outcome matters.
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.jpg)
.jpg)
.png)
.avif)
.avif)
