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.
Free Options
Launch Team / Built With
Tines The single, secure environment for agents, apps, and automations.
Promoted
I've found myself jumpingh between way too many AI tools on a single project so the idea of bringing everything togetehr really stand out. Less context switching usually means I can spend more time building.
@hassan_ismail_rebe Less context switching, more building. That's the whole thesis, glad it lands.
Composer is the piece that makes it real: think n8n + Lovable + Supabase, but as one proprietary stack. Nothing is wrapped, workflows, interfaces, and the database all run on the same core, and you build all of it in natural language without leaving the platform.
Also worth knowing: it's model agnostic. 120+ models supported, with native image and video generation built in. One stack, but zero lock-in on the model side.
@hassan_ismail_rebe @pedrolivares Thanks Hassan! That is indeed one of the main thesis for us. Great to hear it lands the way we hoped it would! :)
i've noticed that AI projects become difficult to manage as soon as more people join team. having everything in one place could make collaboration a lot smoother.
@anthonywrinqsb Yeah, this is one we see constantly. The AI part rarely breaks first, it's the coordination layer around it. One person tweaks a prompt, someone else changes the data schema, and two days later nobody can explain why the agent's behavior shifted.
We actually live this ourselves internally, we're selective about the AI projects we take on, each one led by a small, focused team, but we help each other across projects constantly. Having workflows and traces live as an actual git repo (commits, diffs, branches) helps a lot here, everyone sees exactly what changed and when, instead of "it worked yesterday" being the only explanation you've got.
@anthonywrinqsb totally! thanks for your support!
Congrats on the launch! 🚀
Been using Timbal and honestly having all the tools I need in one place is what sold me, it makes building AI solutions genuinely simple instead of stitching together five different things. And the monitoring side is a huge plus, actually knowing what your agent is doing instead of guessing.
One question: does ACE ever get in the way when a task needs more flexible reasoning, or can you loosen it per agent/step?
@carla_granados_soler Thank you so much for this, and for putting Timbal through its paces on the daily 🙌
Great question. ACE isn't one global switch, it's set per step/agent, so you can tighten it where you want strict guardrails (approvals, writes, anything customer facing) and loosen it where you actually want the model to explore, like open ended research or ambiguous classification.
The mechanism is the easy part honestly, the harder part is knowing where to draw that line for a given use case, we're still learning from real usage what the right defaults should be.
Have you hit a specific case where it felt too rigid? Would love to dig into it with you.
This looks solid. Curious on how things work when building agents in Timbal. How do you compare it with something like Azure AI Foundry?
@jamenos Great question Julia, and Foundry is a fair comparison point.
Building an agent in Timbal: you define it in our open source Python framework (or describe it to Composer in natural language and let it write the code). Tools, sub-agents, and workflow steps are all code you own, and the runtime gives you tracing, evals, and ACE, our behavior enforcement layer, out of the box. Then you ship it directly to web, WhatsApp, email, or voice from the same platform.
Vs Azure AI Foundry, the honest differences:
Foundry is excellent if you're already deep in the Azure ecosystem, its governance and identity story is tied to that world. Timbal is cloud- and model-agnostic by design: 120+ models, no dependency on one provider's ecosystem.
Foundry gives you agent building blocks, but data, UI, and evals often mean pulling in more Azure services (if they exist). In Timbal the AI-native database, the interface builder, and the eval layer are one runtime, not a constellation of services to wire together.
And the export story: everything in Timbal is clean, readable Python you can version control and take anywhere. That's a deliberate anti-lock-in stance.
Short version: Foundry optimizes for only Azure, Timbal optimizes for shipping production agents fast without marrying a cloud. Happy to go deeper on any piece!
@jamenos Different philosophies, really. Foundry is capable but you build inside Microsoft's walls. Their abstractions, their hosting, and a genuinely steep learning curve. Timbal is the opposite bet: agents are plain code you own, integrate with anything, deploy on any cloud or on-prem. No lock-in, and radically simpler. Most teams ship a working app the same week. If you're all-in on Azure, Foundry's fine; if you want speed and freedom, that's us 🙂
The prototype-to-production gap for AI apps is very real. It is easy to get something impressive working in a demo, but then retrieval, orchestration, ui, monitoring, evals, permissions, and governance all become separate problems very quickly. as someone building a product, I can definitely see the appeal of having one place to move from "this agent works locally" to "this is actually reliable enough for users."
Curious where Timbal is strongest today. is it mainly for teams building internal AI workflows, or are people also using it for customer-facing AI products?
@andrasczeizel Appreciate you saying that, means a lot given how much of the last two years went into exactly that side of it.
To your question: honestly, both, but for different reasons. Internal workflows tend to be the fastest wins, teams automating things like tender analysis, data cleanup, or ops tasks that used to eat a huge amount of manual hours. That's usually where clients start because the risk is lower and the ROI is immediate.
Customer-facing is where the governance and observability layer really earns its keep, once an agent is talking to your actual users, "it worked in testing" isn't good enough anymore. You need to know exactly why it made a decision, and you need guardrails that hold even when the input is messy. We've got clients running both today, but if I had to generalize, most start internal and move customer-facing once they trust the reliability layer.
Really like the positioning around helping teams move from AI prototypes to production—it feels like a problem a lot of builders eventually run into. I'm curious, after working with customers, what's the most common reason promising AI prototypes never make it to production? Is it usually reliability, observability, governance, or something else that catches teams by surprise?
@franz_briones Hey Franz! Two things kill most prototypes. First, lack of reliability. MIT found only 5% of AI projects deliver real business value, Gartner puts sustainable production at barely 10%. The rest stalls along the way, not because the model is bad, but because of indeterminism, the same input doesn't reliably give the same output, and there's no control layer to catch it.
Second, specification and adaptability. Dozens of generic tools get you from 0 to 1, a working demo. Very few get you from 1 to 100, and that's exactly where most teams stall, because "impressive in a demo" and "trustworthy enough to put in front of real users" require completely different engineering.
@franz_briones To add to Inés' point - the way we catch that indeterminism is by testing the actual steps an agent takes, not just the final answer. So a test can check that the right tools ran in the right order, not just that the output looked okay, because a wrong-but-plausible-looking answer is exactly the kind of failure that passes a surface-level check and then bites you in production.
How does Timbal handle versioning when you iterate on agents and workflows, and can you roll back to a previous version if something breaks in production?
@eray3y7c Hi Eray! Every workflow in Timbal is a git repo under the hood, full commit history, diffs, branches, all of it. You iterate the same way you'd iterate on any codebase: make a change, commit it, review the diff.
Environments map directly to branches, so promoting from dev to prod is a merge, not a manual copy-paste or a "hope this config matches." Rolling back is just as native. Check out a previous commit and you're back to the exact state that was running before, no separate rollback system to learn.
Basically, if you already know git, you already know how to version and roll back a Timbal workflow.
@eray3y7c to add one thing to what Inés said: this is also why the previews feature exists, you can spin up a live preview of a branch before it ever touches prod, so you catch a bad change on the preview environment before it goes live :)