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.
Free Options
Launch Team / Built With
AWS Activate CreditsCredits that fuel your startup’s next milestone
Promoted
Congrats on the launch! 🚀
Been using Timbal and honestly having all the tools I need in one place is what sold me, it makes building AI solutions genuinely simple instead of stitching together five different things. And the monitoring side is a huge plus, actually knowing what your agent is doing instead of guessing.
One question: does ACE ever get in the way when a task needs more flexible reasoning, or can you loosen it per agent/step?
@carla_granados_soler Thank you so much for this, and for putting Timbal through its paces on the daily 🙌
Great question. ACE isn't one global switch, it's set per step/agent, so you can tighten it where you want strict guardrails (approvals, writes, anything customer facing) and loosen it where you actually want the model to explore, like open ended research or ambiguous classification.
The mechanism is the easy part honestly, the harder part is knowing where to draw that line for a given use case, we're still learning from real usage what the right defaults should be.
Have you hit a specific case where it felt too rigid? Would love to dig into it with you.
This looks solid. Curious on how things work when building agents in Timbal. How do you compare it with something like Azure AI Foundry?
@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!
@jamenos Different philosophies, really. Foundry is capable but you build inside Microsoft's walls. Their abstractions, their hosting, and a genuinely steep learning curve. Timbal is the opposite bet: agents are plain code you own, integrate with anything, deploy on any cloud or on-prem. No lock-in, and radically simpler. Most teams ship a working app the same week. If you're all-in on Azure, Foundry's fine; if you want speed and freedom, that's us 🙂
The prototype-to-production gap for AI apps is very real. It is easy to get something impressive working in a demo, but then retrieval, orchestration, ui, monitoring, evals, permissions, and governance all become separate problems very quickly. as someone building a product, I can definitely see the appeal of having one place to move from "this agent works locally" to "this is actually reliable enough for users."
Curious where Timbal is strongest today. is it mainly for teams building internal AI workflows, or are people also using it for customer-facing AI products?
@andrasczeizel Appreciate you saying that, means a lot given how much of the last two years went into exactly that side of it.
To your question: honestly, both, but for different reasons. Internal workflows tend to be the fastest wins, teams automating things like tender analysis, data cleanup, or ops tasks that used to eat a huge amount of manual hours. That's usually where clients start because the risk is lower and the ROI is immediate.
Customer-facing is where the governance and observability layer really earns its keep, once an agent is talking to your actual users, "it worked in testing" isn't good enough anymore. You need to know exactly why it made a decision, and you need guardrails that hold even when the input is messy. We've got clients running both today, but if I had to generalize, most start internal and move customer-facing once they trust the reliability layer.
Really like the positioning around helping teams move from AI prototypes to production—it feels like a problem a lot of builders eventually run into. I'm curious, after working with customers, what's the most common reason promising AI prototypes never make it to production? Is it usually reliability, observability, governance, or something else that catches teams by surprise?
@franz_briones Hey Franz! Two things kill most prototypes. First, lack of reliability. MIT found only 5% of AI projects deliver real business value, Gartner puts sustainable production at barely 10%. The rest stalls along the way, not because the model is bad, but because of indeterminism, the same input doesn't reliably give the same output, and there's no control layer to catch it.
Second, specification and adaptability. Dozens of generic tools get you from 0 to 1, a working demo. Very few get you from 1 to 100, and that's exactly where most teams stall, because "impressive in a demo" and "trustworthy enough to put in front of real users" require completely different engineering.
@franz_briones To add to Inés' point - the way we catch that indeterminism is by testing the actual steps an agent takes, not just the final answer. So a test can check that the right tools ran in the right order, not just that the output looked okay, because a wrong-but-plausible-looking answer is exactly the kind of failure that passes a surface-level check and then bites you in production.
How does Timbal handle versioning when you iterate on agents and workflows, and can you roll back to a previous version if something breaks in production?
@eray3y7c Hi Eray! Every workflow in Timbal is a git repo under the hood, full commit history, diffs, branches, all of it. You iterate the same way you'd iterate on any codebase: make a change, commit it, review the diff.
Environments map directly to branches, so promoting from dev to prod is a merge, not a manual copy-paste or a "hope this config matches." Rolling back is just as native. Check out a previous commit and you're back to the exact state that was running before, no separate rollback system to learn.
Basically, if you already know git, you already know how to version and roll back a Timbal workflow.
@eray3y7c to add one thing to what Inés said: this is also why the previews feature exists, you can spin up a live preview of a branch before it ever touches prod, so you catch a bad change on the preview environment before it goes live :)
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
I like that you’re combining orchestration, deployment, observability, and evaluation instead of expecting teams to stitch together several different tools. I’m curious how opinionated the evaluation layer is—can teams bring their own eval datasets and metrics, or does Timbal encourage a particular workflow?
@amjad_shaik Good question Amjad! The short answer is that we give you the structure, you decide everything inside it.
Evals in Timbal run on a YAML-based test format, you define the runnable, the inputs, and what "correct" means for that specific case: output validators (type, pattern, semantic match), execution sequence validators (did it call the right tools in the right order), and timing thresholds. None of that is prescribed content, it's your dataset, your params, your definition of a passing result.
Where we're opinionated is the format and the mechanics: a consistent way to write, discover, and run evals via CLI, so they plug into CI/CD the same way across every project instead of everyone inventing their own testing setup. That consistency is what lets Composer also generate a starting set for you if you don't want to write from scratch, but it's optional scaffolding, not a constraint.
@inescastillo That clarifies it well. I especially like that the format is opinionated but the evaluation logic isn’t. I can see how that would make it easier to adopt across multiple projects without forcing everyone into the same testing criteria.