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.
Bringing tracing and evaluation into the runtime is a strong choice. One thing I’m curious about: how do evaluations handle long-running agents whose context changes over time? A workflow can pass step-level checks while gradually acting on stale or contradictory context. Do you evaluate the assembled context itself, or mainly the agent’s resulting actions?
Timbal AI
@amir_mehrabi Sharpest question in this thread, Amir. You're describing a real failure mode: step checks pass locally while the trajectory drifts because the context feeding those steps went stale or contradictory.
We evaluate both, deliberately. Evals can run against any point in the assembled state, including the context itself, not just the resulting action, so you can catch a contradiction before it produces a bad output. And since the full run is traced, evals can also run retroactively across the whole trajectory, which is what actually surfaces slow drift: nothing looks wrong at any single step, but the context now contradicts the context from a few steps back.
Action-only evals catch the wrong output. Context evals catch it before it gets there. Most teams only build the first one until they get burned once.
Love how you're baking governance and step-level tracing into the runtime itself, turning the usual after-the-fact scramble into something you can just replay and inspect.
Timbal AI
@ilko_kacharov Hey Ilko! The alternative most teams end up building is logs scattered across five different tools, and by the time something breaks you're reconstructing what happened from fragments. Baking tracing into the runtime means every step, model calls, tool calls, retries, fallbacks, is already captured as it happens. You're not debugging from memory, you're replaying the exact decision chain.
Timbal AI
@ilko_kacharov Also just checked out Juma AI, the marketing focus is really interesting, that's actually my world day to day. Would love to compare notes sometime 🙌
congrats on the launch!
I am curious, why a company would prefer to use Timbal vs Claude or Devin?
Timbal AI
@0xpili Thanks for your support! The reality is that they're not really direct competitors, more different layers. Claude is a model, you'd actually still use Claude models inside Timbal if you want, we're provider-agnostic, not locked to one. Devin is a specific agent built for one job, writing code autonomously. Timbal is the platform underneath, for a company building multiple different agents across the business (support, ops, internal tools, whatever), each one needs deployment, monitoring, governance, and a place to actually run in production.
So it's less "pick Timbal instead of Claude" and more "Timbal is what you'd use to actually ship and run agents reliably, whichever model or use case you're building for."
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!
Timbal AI
@nayan_joshi Thanks Nayan! The gluing is always the hidden cost, nobody budgets three weeks for "make orchestration, logging, and UI talk to each other" but everyone ends up paying it.
That's exactly the tax we built Timbal to remove. One runtime, so nothing needs to be wired together after the fact.
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 🙌
Lancepilot
Timbal AI
@odeth_negapatan1 Really appreciate that, that framing is basically the whole thesis in one sentence.
On scale: it’s built into the runtime, not bolted on. Evals, observability, and deterministic workflows are native, so a workflow running against real production data is traceable step by step, not a black box that happens to work in the demo.
And yes, open source core is intentional.
Trust should come from reading the code, not from a claim on a landing page. Curious what you’d throw at it first if you tried a real workload.
Timbal AI
@odeth_negapatan1 Appreciate the eyes from someone building in the space too 🙌!! Would genuinely love to hear what you'd stress-test first if you gave it a real workload.