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.
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?
Timbal AI
@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.
Timbal AI
@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?
Timbal AI
@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.
Timbal AI
@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 :)
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
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.
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?
Timbal AI
@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.
Timbal AI
@pablo_veciana For Knowledge Bases specifically, ingestion goes through Timbal's own pipeline today, you add files via direct upload or a remote URL fetch, or upload structured/tabular data directly, and then you can query it (including raw SQL) once it's in. That's the native path, one hybrid store for retrieval.
But KBs aren't the only way to bring in your data. Agents can call external tools directly, including ones exposed via MCP, so if you've got a live data source you don't want to migrate, you connect it as a tool the agent calls at runtime instead of ingesting it into a KB. Timbal itself is also MCP-connectable the other direction, we support connecting to Claude, Cursor, VS Code, and other MCP clients directly.
In conclusion, native KB ingestion for data you want unified and queryable inside Timbal's retrieval layer, MCP/external tools for data you want to keep live and separate.
Timbal AI
@pablo_veciana great question Pablo! Also to build on Inés' reply, once something's ingested, you're not stuck with however it auto-chunked. You can go in and edit individual chunks directly (what gets embedded vs. what gets shown), so that in the case that retrieval quality is off for one document you fix that document instead of having to re-tune the whole pipeline.
Creatium
Timbal AI
@ridhwikvinod On your specific pain point, rollback. Every workflow is a real git repo, commits, diffs, branches. A bad prompt change is just a commit you revert, same as reverting any other code change, no separate rollback UI to figure out under pressure.
On testing before production:,you define evals per step, so you're not just checking "did the final output get worse," you can pinpoint which exact node degraded. Composer can also scaffold a starting eval set for you if writing them from scratch isn't where you want to spend time.
For a 40-person team running this internally without a big platform team behind it, that combination (git-native rollback + step-level evals) is probably what saves you the most time day to day, not because either piece is fancy, but because you already know how to use them.