Build your open and agnostic agent stack

Say you want to build an agent that resolves support tickets against your own data. Not a demo against a toy dataset, an agent that actually runs in production.

The agent itself is maybe a day of work. Getting it into production is the other three weeks: a model gateway so you're not hard-coded to one provider, an orchestrator that can retry a failed step without losing the whole run, somewhere to see what the agent actually did when it gets something wrong, a retrieval layer so it's grounded in your data instead of guessing, and a UI so someone can actually use the thing. Each of those is its own service, its own deployment, its own set of credentials to wire up.

The choices you make along the way are also harder to undo than they look. This market moves fast. The best model today probably won't be the best model in six months, and the same goes for the orchestration framework, the observability tool and the vector store. If any layer of your stack is a closed box, you're one release away from being stuck with it. Lock-in isn't just a question of which model you call. It's a question at every layer.

So the stack worth building is open and swappable all the way down: open-source components, standard interfaces, and a place to run them that you can move off of. Aiven Runtime ships with templates for exactly that, so you deploy the pieces next to your data instead of assembling them from scratch, and swap one out when something better comes along.

The stack, piece by piece

Here's what each layer actually does, and why you need it.

• Talking to the model. Your agent needs to call an AI model, but you don't want to lock yourself into one provider forever. LiteLLM sits in between: one connection point for any model. Want to switch providers, split traffic between two models, or keep an eye on cost? Change a setting, not your agent's code.
• Deciding what the agent does next, and making sure it doesn't fall over. LangGraph is where you define the agent's steps, read this, check that, decide what to do. But agents call a lot of flaky things (APIs, models, tools), and any one of them can fail mid-task. That's what Temporal is for: if a step fails, the agent picks up exactly where it left off instead of starting the whole task over.
• Seeing what the agent actually did. Agents make a lot of small decisions you can't watch happen in real time. Langfuse records every step, every tool call, every token the agent used. When something goes wrong, this is how you find out why, instead of just knowing that it did.
• Giving people a way to use it. An agent isn't useful if it only lives in a terminal. Streamlit gives you a simple interface people can actually click around in. Hasura gives you a real API, so other systems can talk to your data too, without you building either from scratch.
• Running things on a schedule, or in response to events. Not everything needs agent reasoning, sometimes you just need something to run automatically. n8n and Airflow handle that: triggers, schedules, pipelines.
• Finding the right data to answer a question. An agent is only as good as what it can find. For search across a lot of data, use OpenSearch. If your data already lives in Postgres, pgvector lets you search it in place, no second system to keep in sync.
• The agent itself. The part you actually came here to build. Everything above exists to support it.

Each piece is a template. Browse templates.aiven.io, pick what the stack needs, deploy it next to your data. No separate infrastructure to stand up, no plumbing between services you wired up yourself.

What that looks like for the ticket-resolving agent

Point LiteLLM at whatever model you're using today, so switching providers later is a config change, not a rewrite. Put LangGraph in front of it to define the steps: read the ticket, retrieve context, draft a response, decide whether a human needs to see it first. Wrap the run in Temporal so a flaky API call doesn't mean starting over from ticket one. Point retrieval at pgvector if your ticket history already lives in Postgres, or OpenSearch if you're searching across a larger estate. Wire Langfuse in from the start, not after the first time an agent does something inexplicable in production. Put Streamlit in front of it so the support team can actually see what it's doing.

None of that is novel engineering. It's the same handful of services every agentic stack needs, deployed next to the data the agent is supposed to act on, instead of a network hop away from it.

Get started

Browse the templates at templates.aiven.io and deploy the first piece. Everything runs on Aiven Runtime, next to your data, with no plumbing and no lock-in.