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.
Timbal AI
@pablo_veciana For Knowledge Bases specifically, ingestion goes through Timbal's own pipeline today, you add files via direct upload or a remote URL fetch, or upload structured/tabular data directly, and then you can query it (including raw SQL) once it's in. That's the native path, one hybrid store for retrieval.
But KBs aren't the only way to bring in your data. Agents can call external tools directly, including ones exposed via MCP, so if you've got a live data source you don't want to migrate, you connect it as a tool the agent calls at runtime instead of ingesting it into a KB. Timbal itself is also MCP-connectable the other direction, we support connecting to Claude, Cursor, VS Code, and other MCP clients directly.
In conclusion, native KB ingestion for data you want unified and queryable inside Timbal's retrieval layer, MCP/external tools for data you want to keep live and separate.
Timbal AI
@pablo_veciana great question Pablo! Also to build on Inés' reply, once something's ingested, you're not stuck with however it auto-chunked. You can go in and edit individual chunks directly (what gets embedded vs. what gets shown), so that in the case that retrieval quality is off for one document you fix that document instead of having to re-tune the whole pipeline.
Timbal AI
@ridhwikvinod On your specific pain point, rollback. Every workflow is a real git repo, commits, diffs, branches. A bad prompt change is just a commit you revert, same as reverting any other code change, no separate rollback UI to figure out under pressure.
On testing before production:,you define evals per step, so you're not just checking "did the final output get worse," you can pinpoint which exact node degraded. Composer can also scaffold a starting eval set for you if writing them from scratch isn't where you want to spend time.
For a 40-person team running this internally without a big platform team behind it, that combination (git-native rollback + step-level evals) is probably what saves you the most time day to day, not because either piece is fancy, but because you already know how to use them.
How does pricing scale as you add more agents and team members, especially once you start hitting heavier eval runs on bigger workloads?
Timbal AI
@gnepalanclx6es Good question, Güneş. Timbal is pay-per-use, so it scales with actual consumption rather than seat count or a fixed agent limit. You're not paying more just because you added a team member or spun up another agent, you pay for what actually runs.
On top of that, you set well-defined budgets, so heavier eval runs on bigger workloads don't turn into a surprise invoice. You know your ceiling going in, whether you're a small team experimenting casually or an enterprise running production workloads at scale. Predictability was a deliberate design goal, not an afterthought.
If you have a rough sense of your expected volume (agents, workload size, eval frequency), happy to help you sanity-check what that would look like in practice.
how do you manage version control across workflows. a simple visual history could help teams track every important change.
Timbal AI
@darly_selby Great question! Every workflow in Timbal is a git repo under the hood full commits, diffs, branches, the works. You can clone it, review it on GitHub, and roll back exactly like any other codebase. Environments map to branches too, so promoting dev → prod is a merge, not a copy-paste.
Love the visual history idea though!
Me wonder how evaluation works for complex agent systems with multiple steps. Sharing sample evaluation reports would help teams understand how they can improve reliability before deployment.
Timbal AI
@eoin_bishop Great question Eoin, this is exactly the layer where most agent projects fall over.
Evals in Timbal work at two levels. First, natively in the Python framework: you define evals per step or across the whole workflow, so in a multi-step agent system you can pinpoint exactly which node degrades instead of just seeing "the answer got worse." Second, Composer can create those evals for you and wire in ACE (our Action Control Engine) to enforce the expected behavior of each step, so evals aren't just a report you read after the fact, they become constraints the runtime actually holds.
All of this runs in a parallel or pre-deployment environment, so you validate reliability before anything touches production. That's the enterprise-ready part: you're not testing on your users.
On sample reports, fair ask. Attaching a real one below: cost and latency comparison of the same task with ACE on vs. off. Latency 5.17s vs 12.21s, cost $0.007 vs $0.089, one tool call instead of many. Enforced behavior isn't just safer, it's dramatically cheaper and faster because the agent stops wandering.
Congrats on the launch!!
That's a really cool project, I tried to create a simple agent and it really satisfied my expectations.
But what about token usage? isn't it expensive?
Timbal AI
@yernururu Thanks, glad the agent held up! Fair question, and actually it tends to go the other way. ACE stops agents from wandering into extra tool calls, so token usage often drops instead of climbing, and overall ends up more economical 🙂
The "one stack" pitch is appealing — the amount of time spent stitching together separate tools for
retrieval, orchestration and observability adds up quickly. How does it handle model switching mid-workflow?
Curious whether you can swap between providers without rebuilding the whole pipeline.
Timbal AI
@charles_mondal_phd Great question! And yes, that's genuinely just swapping a string, models are referenced as "provider/model" throughout, so switching Anthropic to OpenAI to Gemini mid-pipeline doesn't touch the rest of the logic. You can also chain providers as an automatic fallback (if one fails or times out, it tries the next) instead of hardcoding just one. No rebuild, no separate integration per provider.