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.
No reviews yetBe the first to leave a review for Timbal AI
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.
@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.
The tool-stitching problem is so real. Spent way too long gluing together separate tools for orchestration, logging, and UI. Makes total sense to have one platform for all of it. Congrats on the launch 🎉
@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.
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.
Really like how you framed the “0 to 1 vs 1 to 100” gap, it’s exactly the pain point most teams hit. The unified stack approach feels refreshing compared to juggling fragmented tools. Curious to see how Timbal handles scale in real-world enterprise setups, but the open-source core is a strong signal. Excited to see where this goes!
@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.
@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.
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.
@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 🙌
@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 :)
Report
Congrats everyone! Composer will get the attention because it's the flashy front door, but the real value here is what happens after you build something (how it's run, traced, and governed). That's the part most tools skip and it's exactly where projects usually fall apart once they're live.
@marc_matas Yeah exactly, this is precisely the split we think about a lot internally. Composer is the fun part people notice first, but production is where it actually gets hard. After a bit, "worked in testing" is just not good enough anymore. That's why tracing, evals, and governance are built in from the start instead of something you bolt on after it breaks once. Thanks for your support!!
Report
@marti_norberto I appreciate that this isn't just another agent builder. It feels like you're trying to solve the production side of AI as well. That's the part I usually end up spending the most time on.
@marti_norberto@aduma__emmanuel That's the part that took us the longest to get right, and honestly the part most builders underestimate until they're already in production and things start breaking in ways they can't trace.
Getting an agent to work is the easy 10%. The other 90% is retrieval, observability, evals, permissions, all the stuff that never shows up in a demo but decides whether you can actually trust the thing with real users. That's the whole reason Timbal exists.
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.
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 :)
Congrats everyone! Composer will get the attention because it's the flashy front door, but the real value here is what happens after you build something (how it's run, traced, and governed). That's the part most tools skip and it's exactly where projects usually fall apart once they're live.
Timbal AI
@marc_matas Yeah exactly, this is precisely the split we think about a lot internally. Composer is the fun part people notice first, but production is where it actually gets hard. After a bit, "worked in testing" is just not good enough anymore. That's why tracing, evals, and governance are built in from the start instead of something you bolt on after it breaks once. Thanks for your support!!
@marti_norberto I appreciate that this isn't just another agent builder. It feels like you're trying to solve the production side of AI as well. That's the part I usually end up spending the most time on.
Timbal AI
@marti_norberto @aduma__emmanuel That's the part that took us the longest to get right, and honestly the part most builders underestimate until they're already in production and things start breaking in ways they can't trace.
Getting an agent to work is the easy 10%. The other 90% is retrieval, observability, evals, permissions, all the stuff that never shows up in a demo but decides whether you can actually trust the thing with real users. That's the whole reason Timbal exists.