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.
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)
"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!
@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.
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 🙌
What makes your orchestration different from existing tools? A real customer story would answer that quickly.
Timbal AI
@alheri_murya Fair challenge, Alheri. Two parts to the answer.
First, Timbal isn't an agent project sitting on top of someone else's stack. It's a full suite built on our own proprietary Python framework, where orchestration, evals, observability, and the data layer are all native to the same runtime. That matters because the failure modes of agents in production usually live between tools, and we don't have a between.
A concrete example. For a client automating public tender analysis, we run a workflow that calls different specialized agent nodes: one extracts requirements from the tender docs, one checks them against the client's catalog, one drafts the response. Each node runs with ACE (our Action Control Engine) turned on, which enforces the expected behavior of every step. If a node's output doesn't pass, the runtime retries automatically, and if the primary model keeps failing it falls back to a secondary model, all without a human touching it. And when a step genuinely needs a human, you configure human-in-the-loop directly at the framework level: the workflow pauses, routes to a person for review or approval, and resumes with their input. Every retry, fallback, and decision is traced, so when something looks off we can see exactly which step and why.
In most stacks all of that resilience logic is glue code you write and maintain yourself. Here it's just how the runtime works. Happy to go deeper on any piece of it.