Launched this week
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.
Congrats on the launch!
I spend most of my day talking to enterprise teams who are stuck exactly where you're describing: impressive demo, then six months of stitching together retrieval, observability, and governance before legal will even let it near production. The human in the loop piece is what caught my eye, since "who approved this agent's decision" is usually the question that kills deals late in procurement.
Curious how long your average enterprise sales cycle is now that you've built compliance in from the start, has it actually gotten shorter?
Timbal AI
@pablo_martin6 Yes! Very glad that this part jumped out, because it is exactly one of the reasons why we built human-in-the-loop the way we did. The problem of "Who approved this" used to blow up procurement conversations late in the process, while now it's just logged at the step level, so it's a much quicker turnaround!
Timbal AI
@pablo_martin6 Thanks Pablo, love getting a sales-side perspective on this one 🙌
the trace-at-every-step answer to Shubham's question is the part that sold me, that's the actual difference between a demo and something a team will trust in production. one thing I'd want to understand before committing though: once retrieval, orchestration, UI, observability and evals all live in one core, how painful is it to rip out just one piece later if a team outgrows it or needs something more specialized, or is the whole pitch that you shouldn't need to
Timbal AI
@galdayan The pitch isn't "you'll never need to rip anything out," it's that ripping something out doesn't leave you stuck.
Everything in Timbal, agents, workflows, integrations, compiles down to clean, readable code you own. Nothing is a black box abstraction that only makes sense inside our platform. So if a team outgrows the UI builder, or needs a more specialized eval setup than what we ship, you're not migrating off a proprietary format, you're working with code you can already read, edit, run locally, or self-host.
In practice, most teams don't rip pieces out entirely, they go deeper into code for the specific piece that needs more control while keeping the rest running natively (same pattern Gaspard asked about for interfaces earlier in this thread)
@pedrolivares — the part that resonates: making the resilience logic — per-step retries, primary→secondary model fallback, human-in-the-loop — a property of the runtime instead of glue code every team rewrites and half-tests.
I've watched agent projects die right in that "between the tools" seam, so having ACE enforce expected behavior at each node and trace every retry/fallback is the piece I'd actually trust in production.
Model-agnostic with the fallbacks baked in is the right call too.
Timbal AI
@pedrolivares @akbar_b Totally agree Akbar!
On tracing, every decision runs through ACE, which sits as a proxy on every step, not just logging after the fact. So when something unexpected happens, you're not reconstructing what occurred from scattered logs, you pull the trace directly, step by step, model calls, tool calls, retries, fallbacks, all timestamped and ordered.
"prototypes into production systems" is exactly the right problem to focus on. the graveyard of AI demos that never made it to real users is huge and the gap is almost never the model quality. it's observability, governance, eval pipelines, and the ten other boring things that prototype tools don't include. curious how the governance layer works in practice though. when an agent does something unexpected in production, how quickly can you trace back through the decision chain to understand why it happened?
Timbal AI
@shubham4real Thanks Shubham! It's super fast in practice it's like two clicks. You pull up the execution and see every step the agent took, and for each one the exact input and output. So when something looks off, you don't ned to reconstruct what happened, you just open the trace and see it directly, which makes everything so much more easier!
For teams already using separate best-of-breed tools, like LangSmith for evals, Pinecone for retrieval, and their own orchestration layer, what's the actual migration story? "One platform" is compelling when starting fresh but most teams evaluating this have existing infrastructure they'd be replacing, curious whether Timbal is designed to coexist with those or replace them entirely.
Timbal AI
@ansari_adin Coexistence first, replacement over time, that’s the realistic path, not a forced rip-and-replace.
Most teams don’t tear out LangSmith, Pinecone, and their orchestration layer on day one. New agents and workflows get built natively on Timbal, where evals, tracing, and ACE are already part of the runtime instead of three separate tools bolted together, that’s usually the first piece to get replaced since it carries the most maintenance burden.
Retrieval tends to move last, migrating a production vector store is real, risky work, so existing infra typically stays until there’s an actual reason to consolidate it.
What’s your current orchestration setup look like? That’s usually what determines how a migration would go in practice.
I've built a few AI workflows recently and i've realized the hardest part isn't getting the first demo working it's everything that comes afer. i love that Timbal is focusing on the production side instead of stopping at the prototype.
Timbal AI
@tessa_lynch Tessa, you nailed the exact insight the whole company is built on. The demo is the easy 10%, everything after is where projects go to die.
And it's actually more than production-grade workflows. The full picture:
Native tools across the stack, so you're not maintaining a zoo of integrations. Proprietary infrastructure on AWS with one-click deployments, no DevOps ceremony between you and production. Compliance built in from day one: ISO 27001, SOC 2 Type II, NIS2, because for enterprise that's not a nice-to-have, it's the entry ticket.
And the part that ties it together: you can create all of it in natural language.
Workflows, agents, interfaces, deployments. Describe what you need and Composer builds it on that same production-grade foundation, so "prototype" and "production" stop being two different projects.
Timbal AI
@tessa_lynch @pedrolivares Thanks for the kind words, Tessa! That's really the core belief behind everything we're building. We agree that the demo is the fun part, but then the production part is where most teams actually get stuck, very happy that the focus comes through :)
what stood out to me is that you're thinking about monitoring and evaluation from the start those are usually the things people only worry about after they've already shipped.
Timbal AI
@vincentbanzpk4 Exactly what we're tackling, Vincent. Retrofitting monitoring after shipping is where most AI projects stall, so we made it a property of the runtime instead of an afterthought.
Context on why: we're enterprise-focused, and that market doesn't forgive missing observability or governance. The nice side effect is that SMEs and agencies get the same performance and security machinery out of the box, stuff they'd normally never have the resources to assemble. The reliability layer is a byproduct of building for the hardest customers first.
Timbal AI
@vincentbanzpk4 @pedrolivares totally agree and appreciate you noticing that, Vincent. It's easy to leave monitoring and evals for later and then later never comes... So baking it in from day one was a deliberate call on our end to tackle this specific issue 🙌