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
AWS Activate CreditsCredits that fuel your startup’s next milestone
Promoted
@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.
@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.
@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.
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?
@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.
@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.
Bringing tracing and evaluation into the runtime is a strong choice. One thing I’m curious about: how do evaluations handle long-running agents whose context changes over time? A workflow can pass step-level checks while gradually acting on stale or contradictory context. Do you evaluate the assembled context itself, or mainly the agent’s resulting actions?
@amir_mehrabi Sharpest question in this thread, Amir. You're describing a real failure mode: step checks pass locally while the trajectory drifts because the context feeding those steps went stale or contradictory.
We evaluate both, deliberately. Evals can run against any point in the assembled state, including the context itself, not just the resulting action, so you can catch a contradiction before it produces a bad output. And since the full run is traced, evals can also run retroactively across the whole trajectory, which is what actually surfaces slow drift: nothing looks wrong at any single step, but the context now contradicts the context from a few steps back.
Action-only evals catch the wrong output. Context evals catch it before it gets there. Most teams only build the first one until they get burned once.
Love how you're baking governance and step-level tracing into the runtime itself, turning the usual after-the-fact scramble into something you can just replay and inspect.
@ilko_kacharov Hey Ilko! The alternative most teams end up building is logs scattered across five different tools, and by the time something breaks you're reconstructing what happened from fragments. Baking tracing into the runtime means every step, model calls, tool calls, retries, fallbacks, is already captured as it happens. You're not debugging from memory, you're replaying the exact decision chain.
@ilko_kacharov Also just checked out Juma AI, the marketing focus is really interesting, that's actually my world day to day. Would love to compare notes sometime 🙌
congrats on the launch!
I am curious, why a company would prefer to use Timbal vs Claude or Devin?
@0xpili Thanks for your support! The reality is that they're not really direct competitors, more different layers. Claude is a model, you'd actually still use Claude models inside Timbal if you want, we're provider-agnostic, not locked to one. Devin is a specific agent built for one job, writing code autonomously. Timbal is the platform underneath, for a company building multiple different agents across the business (support, ops, internal tools, whatever), each one needs deployment, monitoring, governance, and a place to actually run in production.
So it's less "pick Timbal instead of Claude" and more "Timbal is what you'd use to actually ship and run agents reliably, whichever model or use case you're building for."