Launching today
Timbal helps teams turn AI prototypes into production systems. Build agents and workflows, connect them to your data, design interfaces, deploy, monitor, evaluate, and govern everything from one platform. Instead of assembling separate tools for retrieval, orchestration, UI, observability, and evals, Timbal gives you one core for shipping reliable AI applications.
how do you manage version control across workflows. a simple visual history could help teams track every important change.
Timbal AI
@darly_selby Great question! Every workflow in Timbal is a git repo under the hood full commits, diffs, branches, the works. You can clone it, review it on GitHub, and roll back exactly like any other codebase. Environments map to branches too, so promoting dev → prod is a merge, not a copy-paste.
Love the visual history idea though!
I enjoy platforms that remove unnecessary complexity. What level of customization do developers have for interfaces. More template examples could help new users build faster.
Timbal AI
@gaspard_dupuich Thanks Gaspard! Short answer: whatever level they want.
Think of it as a Lovable inside Timbal. You can keep iterating with Composer in natural language until the interface is exactly what you had in mind, and if you want to go deeper you can download the code or connect your GitHub and work on it directly. It's real code you own, not a locked template, so there's no ceiling where the builder stops and you're stuck.
On templates: we already ship with them. They're not exposed as a gallery in the platform yet (coming soon), but Composer already fetches them from the backend and picks the ones that match the intent of your prompt. So in practice you're rarely starting from a blank canvas, even if you never see the template library itself.
Curious what kind of interface you'd build first, that helps us prioritize which templates to surface.
Question about ACE: does it work with standard chat completions from OpenAI? Curious if the behavior enforcement sits at the runtime level regardless of which model provider you plug in, or if it needs specific model features to work.
Timbal AI
@miguel_jalon Yes! ACE works with standard OpenAI chat completions out of the box. The behavior enforcement sits at the runtime level, so it's provider-agnostic: OpenAI, Anthropic, open models, whatever you're running.
And here's the part most people miss: ACE is actually a standalone product. You don't need to be building inside Timbal to use it. You can drop it into your own agents and workflows, on your existing stack, and get the same behavior enforcement layer. Integration is genuinely a few lines.
So if switching models isn't trivial for you today, good news: you don't have to switch anything. Bring ACE to the stack you already have.
This looks solid. Curious on how things work when building agents in Timbal. How do you compare it with something like Azure AI Foundry?
Timbal AI
@jamenos Great question Julia, and Foundry is a fair comparison point.
Building an agent in Timbal: you define it in our open source Python framework (or describe it to Composer in natural language and let it write the code). Tools, sub-agents, and workflow steps are all code you own, and the runtime gives you tracing, evals, and ACE, our behavior enforcement layer, out of the box. Then you ship it directly to web, WhatsApp, email, or voice from the same platform.
Vs Azure AI Foundry, the honest differences:
Foundry is excellent if you're already deep in the Azure ecosystem, its governance and identity story is tied to that world. Timbal is cloud- and model-agnostic by design: 120+ models, no dependency on one provider's ecosystem.
Foundry gives you agent building blocks, but data, UI, and evals often mean pulling in more Azure services (if they exist). In Timbal the AI-native database, the interface builder, and the eval layer are one runtime, not a constellation of services to wire together.
And the export story: everything in Timbal is clean, readable Python you can version control and take anywhere. That's a deliberate anti-lock-in stance.
Short version: Foundry optimizes for only Azure, Timbal optimizes for shipping production agents fast without marrying a cloud. Happy to go deeper on any piece!
Timbal AI
Hey Product Hunt 👋🏻
I'm Martí, co-founder and CEO of Timbal AI.
In today's AI world, going from 0 to 1 it's easy fast and cheap, going from 1 to 100 is not.
Complex data, legacy software, messy folders and heavy compliance and cybersecurity requirements, that's the enterprise reality.
You can prototype an agent in an afternoon, but then the real work starts. You have to wire together a vector database, an orchestration framework, a UI tool, and an observability layer. Before you know it, you're maintaining a fragmented stack of vendors, and your app still breaks in ways you can't easily trace.
Timbal is the unified stack that closes that gap. Everything you need to go from idea to production lives in one place:
A Database Native to AI: Run vector, keyword, and relational searches in a single query, ensuring your agents are always grounded in your actual data.
Deterministic Workflows: A reliable runtime for agents with built-in observability, traceability, and evals. You will always know exactly why your AI made a specific decision.
Omnichannel Visual Builder: Turn your logic into real apps instantly. Ship directly to the web, WhatsApp, email, or voice.
Our core is open source (Python framework, NPM packages, and TypeScript SDK on GitHub). You can stay in the code, build visually, or seamlessly mix both.
Putting this in front of the PH community is the milestone we’ve been waiting for. We want your brutal feedback—tell us what you'd build, what's missing, and where you think we're wrong.
Let's chat in the comments!
Martí & the Timbal team
Me wonder how evaluation works for complex agent systems with multiple steps. Sharing sample evaluation reports would help teams understand how they can improve reliability before deployment.
Timbal AI
@eoin_bishop Great question Eoin, this is exactly the layer where most agent projects fall over.
Evals in Timbal work at two levels. First, natively in the Python framework: you define evals per step or across the whole workflow, so in a multi-step agent system you can pinpoint exactly which node degrades instead of just seeing "the answer got worse." Second, Composer can create those evals for you and wire in ACE (our Action Control Engine) to enforce the expected behavior of each step, so evals aren't just a report you read after the fact, they become constraints the runtime actually holds.
All of this runs in a parallel or pre-deployment environment, so you validate reliability before anything touches production. That's the enterprise-ready part: you're not testing on your users.
On sample reports, fair ask. Attaching a real one below: cost and latency comparison of the same task with ACE on vs. off. Latency 5.17s vs 12.21s, cost $0.007 vs $0.089, one tool call instead of many. Enforced behavior isn't just safer, it's dramatically cheaper and faster because the agent stops wandering.
i like products that solve workflow issue instead of adding another tool to the stack. if Timbal can replace a few separate services that 's already a big win in my book.
Timbal AI
@georgiafor9p Georgia, that's the whole bet we're making. Every "just add one more tool" decision feels small in the moment, but a year in, most teams are maintaining a stack nobody fully understands anymore, including the people who built it.
Timbal replaces the orchestration layer, the data layer, the UI layer, and observability in one runtime. Not five vendors talking to each other through glue code, one system that already knows about all the pieces.
Timbal AI
@georgiafor9p Indeed! And this is one of the main bets we are making. Most teams end up with a vector DB, an orchestration framework, a UI tool, and an observability layer, all coming from separate vendors and having their own quirks, so it involves a lot of work to glue them together instead of building the actual product.
With Timbal, knowledge bases and retrieval run on our own hybrid DB engine instead of a separate vector DB, the UI builder is native, and observability and evaluations are part of the runtime instead of a dashboard. This means that Timbal allows you to have the four or five tools you'd normally stitch together but already in the same place and seamlessly talking to each other.