Your AI Coding Assistant Doesn't Know Your Project. Let's Fix That!

A joint webinar from Dosu and DBOS on MCP, agents, and resiliency: how the Dosu MCP server turns one agent's research into shared knowledge for every future session, and how DBOS keeps Dosu's long-running workflows durable.

Transcript

Taylor Dolezal, Head of Open Source, Dosu: Alright, howdy everybody — we've got our bits, bytes, and everything else together. Welcome to our webinar between Dosu and DBOS. Today you're going to hear from Devin and Alex; I'll let them introduce themselves. If you've got questions, drop them in the chat and we'll field as many as we can. We're looking forward to talking about MCP, agents, and resiliency. With that, I'm going to fade into the background — say my name three times and I'll reappear. Devin, kick it off.

Devin Stein, Founder and CEO, Dosu: Great to see everybody — thanks, Taylor, and thank you all for joining. I'm Devin Stein, the founder of Dosu. I'm excited to be here with Alex and the DBOS team. We'll get more into what Dosu and DBOS are, but spoiler alert: a lot of Dosu is built on DBOS, and we've also been helping support the DBOS team. Alex, want to introduce yourself?

Alex Poliakov, Customer Solutions Lead, DBOS: Hello — Alex Poliakov, a database internals engineer by training. I started facing customers and now run customer solutions at DBOS. Great to be with you, Devin, and looking forward to chatting about what we do.

Devin: To start, we'll chat through some context about what Dosu is and the problem we're solving, then explain a bit about DBOS and how we use it, and then get into a demo.

What is Dosu? Knowledge infrastructure for AI

Devin: Today we're going to be talking about the Dosu MCP server, but I want to give some context on how we ended up building the MCP tools we did — the story of how we learned what's useful to agents building Dosu, how we've used this internally, how companies are using it, and now how we're bringing the same tools to open source.

A little about Dosu: we automate knowledge transfer between humans and agents. We like to think of ourselves as a knowledge infrastructure company — really trying to rethink what documentation and knowledge management look like in the era of AI. For the past twenty-plus years, documentation and knowledge management at companies has always been best-effort on product and engineering teams. With LLMs, we have the opportunity to build the dream of knowledge management: you focus on building, Dosu takes care of documenting.

Importantly, we don't just help generate knowledge — we keep it in sync. As code changes, we make sure that's reflected in your knowledge base, and then make it accessible wherever it's needed. For humans that could be GitHub issues, where Dosu helps with triage, or Slack channels, for answering questions about the product or debugging customer support issues. And now MCP as well, for agents working on similar types of tasks.

Why knowledge sharing is broken for agents

Devin: The focus on MCP came up over the past year as agents have grown in popularity. We started to notice — both from building Dosu and from customers — that sharing is broken within agents. That means a few different things.

One: when people would plug documentation into agents — say, connect Confluence to their agent — they'd quickly find out that 80 to 90% of their docs were stale. They were out of sync with the codebase, and often actively harmful to the agent rather than helpful, pointing it in the wrong direction and confusing it. That's because knowledge currently evolves separately from code: code is constantly changing, and knowledge typically doesn't keep up.

The other side is that agents often solve the same problem many, many times. If you're a power user of Cursor or Claude Code or Codex — name your favorite agent — they always start with the same process: let me explore the codebase and look for information before trying to solve the task. They do this every single time, which is a very inefficient and slow way of solving problems.

How agents should learn like engineers

Devin: The way we wanted to solve this at Dosu: agents should learn the way engineers share learnings. Your ideal engineer builds a feature or debugs an issue and writes up their learnings afterward, so the next person who works on that feature or hits a similar issue has a starting point.

Documentation has always been a collective knowledge cache for teams — and we think of it the same way for agents.

A document is an artifact where someone spent time learning about something and distilled their thoughts into a condensed article that other people can reference in the future, so they don't have to repeat that same reasoning and research process.

Self-documenting PRs and keeping docs in sync

Devin: Documenting is only one part of the solution. Writing things down is great, but docs quickly go stale. With Dosu, we help with the end-to-end knowledge lifecycle — we also keep your documentation up to date. We call it self-documenting PRs, or knowledge reviews. Every time a user opens a pull request, we review your knowledge base with respect to that PR, figuring out how knowledge should evolve with it — solving the age-old problem of keeping your knowledge side by side with your code.

And lastly, the vision is knowledge that finds you. Historically, people always had to go find information — searching pages in Notion or Confluence on best-guess terms, maybe finding out it was never documented, or digging through an open source project's code because the docs were unclear. We want to build a future where the knowledge you need for the task at hand is automatically surfaced when you need it — whether that's in your IDE via MCP, in Slack, or on pull requests.

Why durable execution matters for AI workflows

Devin: Today I'll be doing a demo on top of DBOS with a really exciting new feature they launched. But first — why are we working with the DBOS team? A lot of these workflows are complex, long-running workflows. For every single GitHub commit we do incremental knowledge reviews; for every message that comes through Slack or GitHub issues, for every session with Claude Code or an agent, we're kicking off long-running workflows. Finding which documentation you need to update — especially for large organizations with thousands or tens of thousands of articles — takes time, and sifting through code takes time. So durable execution is really important to us. We spent last year migrating from our bespoke solution to DBOS to support all the workflows I'm going to talk about and demo today. With that, I'll hand it off to Alex to give more context about DBOS.

What is DBOS? Reliable workflows with Postgres

Alex: Thanks so much, Devin. We are database experts — database researchers and veterans of the database world — and our mission is to make it as easy as possible for you to build reliable applications: durable workflows, queues, scheduling. We architected things so that DBOS runs completely inside your app process, without a separate orchestrator to call out to, and we use a database for all of the durability needs.

The way it works: you import an open-source library into your app or agent and connect it to your database. Right now we support Postgres, and we're adding support for other engines soon. There's an optional management console we call Conductor, which helps with things like autoscaling to a large app with lots of workers and handing off work from one worker to another. It's all built in the name of simplicity — very easy to get started, and all you need is Postgres.

If you have Postgres, you can DBOS.

That means you can create queues, run durable workflows, checkpoint state, and recover from failures. You add decorators to your code — for steps, workflows, schedules, queues, and so on. We support Java, Python, Go, and TypeScript, and growing. Today we'll be focusing on Python.

Why AI agents need durability and checkpointing

Alex: It's interesting — when we originally created DBOS, we were thinking about applications in banking, reliable payments, financial transactions, e-commerce, maybe industrial control. But increasingly we're finding more and more usage in agentic AI use cases. Why use durability for your AI agents?

As Devin mentioned, AI workflows tend to be long-running. If something runs for a long time, you want to checkpoint its state so that in the event of a crash you don't redo work you've already done. And another thing we're seeing: humans don't trust AIs very much yet, so you may need a human approval workflow. As soon as you add human approval, something that ran in minutes now potentially runs for days, because a human can take days to react and approve. Having a database that checkpoints your state really helps in that scenario.

Dosu has pretty much implemented this: they have a question-answering system where, before answering a question to the knowledge base, Dosu can ask a human for approval — and the human can even edit the response before approving it. All of it is tracked in your Postgres database. Another benefit of having the database is that all past interactions are tracked and saved durably. We can use them to recover, to learn — you can even mine that data to see which workflows are popular and where the errors are. Great observability as well.

Debugging non-deterministic agents with DBOS fork

Alex: Another reason people build agents with DBOS is that agents tend to be long-running as well as non-deterministic. An agentic loop may take a non-deterministic trajectory, where every iteration the agent decides what to do next: do I call this tool, scrape this web page, read this document? That loop where the LLM makes a decision every iteration is very powerful — and also a non-deterministic nightmare for debugging, because no two runs are the same.

With DBOS, we can save the entire path. If your agent wandered off and hit a situation where you had a bad prompt, for example, we can go to the database, find the previously executed path, and rerun that path on a new version of the code — testing whether a bug fix worked, or recovering from a failure. Say you had an outage and a thousand workflows from last night were affected: you can use this fork capability to recover once service is restored. Once you checkpoint something, you have power over it. You can observe previous runs, recover from failures, and run what-if scenarios: would this path work differently on this code?

Hopefully that gives you a flavor of who we are and what DBOS does. Check us out at dbos.dev, and our docs are at docs.dbos.dev. You can get started in a few minutes. Devin — let's dive into your demo.

Demo: live knowledge sync on a DBOS pull request

Devin: Thanks, Alex. There are some nice parallels here: what we're building on the Dosu knowledge side isn't durable checkpointing exactly, but it is an LLM approach to checkpointing agents' learnings.

I want to talk through a recent DBOS PR that's a really good example of where knowledge management is hard and where Dosu shines. DBOS recently redesigned the way they do workflow scheduling — a huge change, thousands of lines of code — adding a lot more flexibility and customization to how you can do scheduling. A big change like this is one a lot of users are excited to try.

On this PR you'll see an example of Dosu keeping knowledge in sync. It's funny how recent this is: we had a saved document in DBOS's knowledge base from a previous conversation between the Dosu and DBOS teams about this very thing. Coming from a Celery background, we were trying to understand where DBOS actually stores scheduled workflows — and in the previous design, workflows were never persisted to the database; they were kept in memory in your workers. This PR changed that, and now they're stored in the database.

Dosu picked that up and commented on the PR: something previously saved as knowledge is changing, and it suggests an update. Once the PR merged, Dosu automatically pushed the update to the document — it went from saying scheduling was in-memory to describing where it lives in the database. This is useful not just for keeping docs up to date, but because when people ask about this in the future, they won't get a stale answer — which is really common when you want these long-tail, FAQ-style answers you can rely on.

Generating migration docs with the Dosu MCP

Devin: Now let's say we're going to migrate to the new DBOS syntax. Something you can do with Dosu is generate a document about a project. In this case: I'm going to work on this migration — generate a document about it. That kicks off a job to generate a new knowledge artifact about how to do the migration given this PR. It looks through all the connected data sources — documentation, the PR we were just looking at, other relevant PRs, and the code before and after — and creates a nice comparison of what to do and how to migrate. Now that's broadly accessible and shareable to anyone who uses DBOS.

How agents cache knowledge across sessions

Devin: What's really cool is that while Dosu is creating this document, it's learning a lot about DBOS — and it creates what we call topics. These are things it learned while documenting the migration. It learned how scheduler coordination works across DBOS workers, saved that knowledge, and created a knowledge index — a topic page — about how scheduling works. Similarly, there was a patch fixing scheduling for class-based workflows, so it learned about class-based workflows during its research and created a new knowledge article for those too.

This has been really powerful for us internally. Dosu is deployed on thousands of projects, in open source and inside companies, and people ask a lot of questions about similar topics — maybe a recently released feature that's going to get lots of questions. We built this as a way to cache knowledge between agent runs. And since Dosu is already keeping knowledge up to date, we keep these knowledge indexes up to date for future agent runs too — making them faster and cheaper.

Decentralized knowledge sharing via MCP

Devin: We've now almost decentralized this learning process, exposing API endpoints through our MCP that allow any agent — not just Dosu — to contribute knowledge back to knowledge bases like DBOS's.

Say I'm a big power user of Claude Code. I open it up and ask: how do I migrate from the old scheduling workflow syntax to the new one? Claude does a bunch of research, exploring the scheduling patterns before and after, similar to the document Dosu generated. Thousands of developers are going to ask the same type of question when they upgrade their existing workflows to the new scheduling syntax.

Currently, a lot of that learning is thrown away. After the agent figures out how the new scheduled workflows work in DBOS, that learning is isolated to that single session of that one developer. What we've introduced is the same thing we built internally: a save-topic MCP tool. After your agent finishes researching a topic, it saves that information back to Dosu — "hey, I just learned about the scheduler migration." On the backend we figure out whether it makes sense to document — maybe it's too specific, or overly generic, and we filter it out. Then: is this already documented? If so, we match it to existing documentation. If not, we kick off the job to generate that knowledge index article. The next time someone asks a question, the agents will actually have learned.

Teams have been using this internally at companies: when I'm working on a feature using Claude and someone else works on a similar feature using Claude, learnings are shared across our sessions. And because these knowledge index articles are materialized in our UI, it's a really nice form factor for both humans and agents — you get documentation for free as you use the product.

What's exciting about open source — and a little preview of what's coming soon — is that those learnings can't just be shared across your team, but actually contributed back to the open source projects themselves. If one developer upgrades their workflow syntax, the learnings from their Claude Code, Cursor, or Codex session can be used by all the other developers using coding agents on similar tasks. We're excited about opening up the same primitive we've used with internal engineering teams to make knowledge sharing on open source projects more democratized.

Initialize knowledge: targeted context for agents

Devin: The way this ends up looking: when you ask a question, the agent uses an initialize-knowledge tool where it describes what it's working on to Dosu, and our job is to look through your knowledge base and distill the most relevant information for the task at hand. It's very targeted context — we're not just returning documentation pages. Because we get context about the task at hand, we can distill it down to exactly what's relevant.

Results: 50% cost reduction, less variance

Devin: The performance gains for internal companies have been pretty huge. When there are knowledge cache hits — when there's a knowledge article about the topic the user is working on — the actual cost of the run is as much as half as expensive.

What was really fun about doing this performance analysis is we got to run Claude Code on the same tasks tens of times, and found there's really high variance in coding agents still. Duration, cost, and tokens can vary widely even for the same task — run Claude Code ten times on the same task and you might get eight different outcomes, in cost, time, and the actual code change.

Because you get this knowledge up front, it's almost like starting with a consistent seed for your coding agent session.

Because you have that consistent starting point, your runs become a lot more predictable — instead of eight different outcomes you get two, and they're faster and cheaper. We'll be pushing a lot more features related to this soon.

And all this information plugs into the existing Dosu infrastructure: we keep it up to date as code changes, and make it accessible not just to coding agents but to people too — Slack is probably the most common way people use Dosu inside companies.

Live demo: Claude Code + the Dosu MCP server

Devin: Here's a Claude Code session showing what I just walked through. When you ask Claude to work on a task, it uses the Dosu MCP to initialize, and the output is a very condensed format of all the relevant knowledge. From there it can make targeted follow-ups: instead of researching the entire codebase, it knows what to look for and where. We're very intentional about linking out to relevant code files and pull requests, giving the agent all the links it needs for an effective follow-up search for any incremental knowledge. You see it quickly find the rest of the information from the code definition files and come up with an answer.

We released this Dosu MCP and it works really well for internal teams — the results have been awesome. This is a bit of a preview: it's possible to use with open source today, and we're going to make it much, much easier in the coming weeks and months. A teaser of what's to come and how we're thinking about Dosu's position in open source evolving.

Alex: I should make one correction to what I said earlier — I said go check out our docs page. That's wrong: ask Dosu about DBOS. In this day and age where humans no longer read docs, just have your Claude talk to Dosu and see if DBOS is right for you.

Devin: The reality is — and there are statistics on the web to show it — agents have become the number one consumer of knowledge. I think it's important to still have documentation as a referenceable artifact, and humans do sometimes want to read docs. But yes: these days, talk to Claude, it'll use Dosu and grab your information.

Q&A: data privacy and preventing info leakage

Taylor: One comment from the chat: please add txt docs for easy ingestion — some folks have been crawling docs with NotebookLM.

Alex: Worth noting — correct me if I'm wrong, Devin — Dosu can pull in markdown files if you've connected through GitHub, so you can add that to your knowledge base.

Devin: Really good point. I showed Dosu generating net-new docs, but we also integrate with existing documentation — and honestly, we should connect the DBOS documentation as well. If you have documentation in GitHub, Confluence, or Notion, Dosu can help you manage those docs too. It's not just the documentation Dosu generates.

Taylor: While we wait for questions, one for you, Devin: any surprises while working with Dosu — did it take any left turns you didn't expect, or source something you didn't realize existed?

Devin: There have been a number of scenarios where I've been surprised that Dosu had already documented something I was looking for. That's the really nice thing about the ergonomics of this approach: you don't have to think about documentation anymore. As long as you have the MCP hooked up and you're using Claude or something similar in your workflow, you build up knowledge automatically, and we help prune, consolidate, and evolve it over time. All of a sudden it's "oh, I didn't even know we had documentation for this — but we do." That's the experience we're going for.

Taylor: We had a question from the chat: how do you guarantee you're not leaking private info or context from users?

Devin: Great question. This can be looked at from multiple angles. Specifically for the MCP workflow we walked through: what's emitted from the agents is only the simple topic level. When we actually generate the knowledge artifact, it only uses DBOS's data sources — it's independent of the person. The workflow we're encouraging is: your agent says what it's using in DBOS, and then a separate agent that only has access to DBOS's data sources goes off and hydrates that with the relevant information about those topics. There's a separation between your personal work and the ultimate artifact, which is based only on the public information that's connected.

Second, on private information: another thing people use Dosu for is maintaining public docs informed by private information — we do this internally, and some customers do too. Prompting goes a long way in terms of keeping out information that shouldn't be there, but you always want a human in the loop for that scenario; we don't suggest going autopilot. We have a really simple way in the app to review messages before they're posted, or documentation updates before they go live.

Q&A: how Dosu integrates DBOS at scale

Devin: A question came in on how Dosu integrates DBOS. It orchestrates most of our backend. You can think of Dosu as two systems. One is background indexing workflows, where we're constantly indexing information from GitHub and all the connected data sources — GitHub, Slack, Confluence, Notion, and so on. We use DBOS to orchestrate those indexing jobs as scheduled workflows; indexing usually happens every two and a half minutes. The other side is event-driven: any time a commit happens, a PR is opened, an issue is created, or a Slack message comes in, we kick off a bunch of workflows — typically agents, but not always. DBOS orchestrates those, and the agents themselves. Our agents are long-running — document generation for large projects can take 30 minutes or more — and DBOS helps us monitor that and keep it reliable, even if a node dies mid-run.

Q&A: scaling DBOS with Postgres

Taylor: George asks: on DBOS, what are some best practices for setting it up the first time so it scales well?

Alex: Because we're Postgres-centered, all of your scaling relates to your Postgres database. If you have a Postgres setup in-house, you may already have a sense of how many operations per second you're running. Usually a beefier medium-to-large Postgres can handle thousands of writes per second, and in DBOS that translates directly to thousands of workflows per second, because every workflow is a couple of writes. You can scale your Postgres up higher if you need. Devin, how did that work for you? Did you need to increase your Postgres at all?

Devin: We use Supabase as our Postgres provider and got started pretty simply — we had a pretty beefy instance and shared our application database with our DBOS database, and it worked pretty well. As we scaled up DBOS usage, particularly for use cases like agents where latency matters more, we noticed that because our Supabase instance wasn't in our VPC, the round trips over the internet were slow — not crazy slow, but at our scale, around 70,000 workflows per hour, it started to get noticeable. So we separated out the Postgres instance for DBOS and deployed it directly in our VPC, and now it's humming — no issues at all.

Devin: There was a follow-up from the chat about running DBOS in a separate process versus the main one. A very simplified version of our architecture: we have a public-facing API where all webhooks and events go, and a separate internal service handling all background work — that's where all our DBOS workflows run. We're trying our best to scale that vertically as much as possible and keep the system simple. We do have workflows with different resource constraints — the indexing side is more memory- and CPU-intensive — and we're considering splitting those into their own service at some point, but right now we get by vertically and horizontally scaling a single service.

Closing thoughts and what's next

Devin: If you're using coding agents to develop on top of open source — which I think is every developer — we'd love to chat and get your feedback on the MCP side. We're really excited about the future of knowledge infrastructure. In a world where coding agents are doing a lot of development, it's a renaissance for knowledge, because agents can be a lot more diligent than humans ever were about sharing knowledge back and keeping things up to date. From a maintainer's perspective, we're also excited about the insights we can bring back to open source projects about how people are using them. Whether you're building on top of DBOS or other open source projects, or you have lots of repositories internally and want better knowledge sharing on your teams — we'd love to talk to you.

Otherwise, thank you so much for joining, and a shout-out to the DBOS team for creating DBOS and for being here.

Alex: This is just an amazing partnership. Thank you for making our docs so accessible and legible to the agents, and for helping all the agents build with DBOS. Really an awesome story we put together.

Taylor: Thank you both for sharing everything today — it was a wonderful session. Thanks everybody for joining and asking such awesome questions, and we'll catch you all soon. Cheers!