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.
Me wonder how evaluation works for complex agent systems with multiple steps. Sharing sample evaluation reports would help teams understand how they can improve reliability before deployment.
Timbal AI
@eoin_bishop Great question Eoin, this is exactly the layer where most agent projects fall over.
Evals in Timbal work at two levels. First, natively in the Python framework: you define evals per step or across the whole workflow, so in a multi-step agent system you can pinpoint exactly which node degrades instead of just seeing "the answer got worse." Second, Composer can create those evals for you and wire in ACE (our Action Control Engine) to enforce the expected behavior of each step, so evals aren't just a report you read after the fact, they become constraints the runtime actually holds.
All of this runs in a parallel or pre-deployment environment, so you validate reliability before anything touches production. That's the enterprise-ready part: you're not testing on your users.
On sample reports, fair ask. Attaching a real one below: cost and latency comparison of the same task with ACE on vs. off. Latency 5.17s vs 12.21s, cost $0.007 vs $0.089, one tool call instead of many. Enforced behavior isn't just safer, it's dramatically cheaper and faster because the agent stops wandering.
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!
Question about ACE: does it work with standard chat completions from OpenAI? Curious if the behavior enforcement sits at the runtime level regardless of which model provider you plug in, or if it needs specific model features to work.
Timbal AI
@miguel_jalon Yes! ACE works with standard OpenAI chat completions out of the box. The behavior enforcement sits at the runtime level, so it's provider-agnostic: OpenAI, Anthropic, open models, whatever you're running.
And here's the part most people miss: ACE is actually a standalone product. You don't need to be building inside Timbal to use it. You can drop it into your own agents and workflows, on your existing stack, and get the same behavior enforcement layer. Integration is genuinely a few lines.
So if switching models isn't trivial for you today, good news: you don't have to switch anything. Bring ACE to the stack you already have.
Timbal AI
@miguel_jalon Thank you for your support Miguel!
"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?
@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
Hey PH! Pedro here, Head of Product at Timbal.
Martí covered the big picture, so I wanted to add a bit on Composer specifically, the piece I spent the most time on for this launch. Most no-code builders get you 80% of the way and then you hit a wall the moment you need real logic, a tricky auth flow, or a data model that doesn't fit the template. Composer lets you drop into actual code right at that point, no rewrite, no migration to a "real" stack later.
If you've ever hit that wall with another builder, I'd love to hear what broke it for you. That's exactly the kind of feedback that shapes what we build next.
Thanks for checking us out today 🙌
Agent 37
i find myself switching between too many AI tools during a signle project. having one platform for the whole workflow sounds much more manageable . less time configuring tools usually means more time improving the product itself.
Timbal AI
@amanda_silmon That's the exact reason this whole thing exists, Amanda!
We got tired of watching people spend more time configuring tools than actually building the thing they cared about.
Since you're here and clearly get it, we're giving away 40,000 free credits right now for anyone who wants to put Timbal through a real project. Would love to see what you'd build with it 🙌
Timbal AI
@amanda_silmon @inescastillo Thanks for the support, Amanda! I used to have the same issue before Timbal, it saves a lot of time and makes everything much more efficient :)