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.
I've built a few AI workflows recently and i've realized the hardest part isn't getting the first demo working it's everything that comes afer. i love that Timbal is focusing on the production side instead of stopping at the prototype.
Timbal AI
@tessa_lynch Tessa, you nailed the exact insight the whole company is built on. The demo is the easy 10%, everything after is where projects go to die.
And it's actually more than production-grade workflows. The full picture:
Native tools across the stack, so you're not maintaining a zoo of integrations. Proprietary infrastructure on AWS with one-click deployments, no DevOps ceremony between you and production. Compliance built in from day one: ISO 27001, SOC 2 Type II, NIS2, because for enterprise that's not a nice-to-have, it's the entry ticket.
And the part that ties it together: you can create all of it in natural language.
Workflows, agents, interfaces, deployments. Describe what you need and Composer builds it on that same production-grade foundation, so "prototype" and "production" stop being two different projects.
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.
what stood out to me is that you're thinking about monitoring and evaluation from the start those are usually the things people only worry about after they've already shipped.
Timbal AI
@vincentbanzpk4 Exactly what we're tackling, Vincent. Retrofitting monitoring after shipping is where most AI projects stall, so we made it a property of the runtime instead of an afterthought.
Context on why: we're enterprise-focused, and that market doesn't forgive missing observability or governance. The nice side effect is that SMEs and agencies get the same performance and security machinery out of the box, stuff they'd normally never have the resources to assemble. The reliability layer is a byproduct of building for the hardest customers first.
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.
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.
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.
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.