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.
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.
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.
Timbal AI
@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.
Timbal AI
@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.
Timbal AI
@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.
Timbal AI
@anthonywrinqsb totally! thanks for your support!
How easy is it to migrate an existing project into Timbal. A guided import feature would make adoption much easier.
Timbal AI
@advin_jadis Great question, and honestly the guided import you're describing pretty much exists, it's called Composer. Two ways to migrate today: 1. Send your code or workflow directly to Composer, our super agent. It can translate workflows from Make, n8n, and other providers straight into Timbal, so you're not rebuilding node by node. 2. Connect your GitHub repo and let Composer manage the migration from there: it reads your existing project and brings it into the Timbal stack. Either way you end up with a native Timbal workflow, with the eval and observability layer on top from day one, not a wrapper around your old setup. If you have a specific project in mind (a Make scenario, an n8n flow, a repo), try throwing it at Composer and tell us where it struggles. That feedback is gold for us right now.
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?
Timbal AI
@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?
Timbal AI
@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!
Timbal AI
@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?
Timbal AI
@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.