Wispr Flow: Dictation That Works EverywhereStop typing. Start speaking. 4x faster.
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 appreciate that you're trying to simplify the AI development process without hiding the important pieces. reliability and visibility become much more valuable as projects start to grow.
Timbal AI
@sarahjadefi Really appreciate you naming that Sarah, because it's a distinction we care about a lot. Simple shouldn't mean hidden, it should mean you're not fighting the tool to see what's actually happening.
That's why everything runs with full observability and evals from day one, not something you bolt on once things start breaking. As a project scales, that visibility is usually the difference between "we caught the issue in staging" and "we found out from an angry user."
Timbal AI
@sarahjadefi @inescastillo Thank you for your support Sarah! Indeed that distinction is super important for us! Keeping things visible even as it stays easy to use is key to success!
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.