Daimon — From AI Experiment to Company Operating System
For the past year, I have been part of an experiment at PyMC Labs: what does it mean to be AI-first when the AI is not another private tab, but a colleague in the place where the company already talks?
I call that colleague Daimon. It began as a scrappy internal idea. Today it is the agent PyMC Labs uses in team chat to pull context together, run analysis, build notebooks, investigate code, and turn the result into something the rest of the team can inspect. PyMC Labs has now released the core project as open source.
This is my recap of the webinar Data Science Agents in Your Team Chat: From Data to Insight Without Leaving the Channel. The recording has the live walkthroughs; below I want to pull out the organizational change that made the project matter to me.
I wanted to find out what AI-first meant
About a year ago, “AI-first” was everywhere and still meant almost nothing operationally. I did not want a slogan. I wanted to see what happened if an agent could participate in everyday work instead of being something a few people opened when they had time to experiment.
At PyMC Labs, that everyday work happens in Discord. That made it the obvious place for the experiment. The agent could read the thread it had been called into, use the tools and context the team made available to it, and return work to the same conversation.
That sounds like an interface decision. It turned out to be a much bigger one. Once the agent sat in the shared place where a question started, it could inherit the discussion, leave an artifact for the next person, and be challenged in public. The aim was never to replace judgment. It was to take more of the glue work out of the path between a question and a useful answer.
The private-tab loop was the real friction
The old loop is familiar: someone asks a question in team chat, one person copies the relevant messages and documents into a private AI session, then carries the answer back. The person doing the copying has to reconstruct the context. Everyone else has to trust their summary. The useful bit of the interaction is stranded in a tab that the team cannot see.
That pattern is not just slow. It keeps AI work single-player.
The point is not that every request should be delegated. The point is that the interface can stay the same as the request becomes more ambitious. “Where was that thread?” and “can you reproduce this paper and open a pull request?” can both begin with a message in the channel where the work is already being discussed.
Four things changed once the agent joined the conversation
The first surprise was adoption. People who would never set up an agentic coding environment will still ask a question where they already communicate. They also see colleagues use the agent well, borrow the pattern, and adapt it. That visible learning has been more important than any top-down training programme.
Second, an agent can make the right company tools reachable from one place. A question about marketing performance should not die because the person asking is not the person with access to the relevant data or does not know which dashboard contains it. Access still needs to be carefully designed, but the question can at least start in the open.
Third, the team’s standards can become easier to follow. A good workflow often contains a pile of hard-won preferences: how a blog post is reviewed, how an analysis is structured, what checks make a pull request safe to merge. When those preferences live in a skill the agent can use, the path of least resistance is closer to the team’s actual standard.
Finally, knowledge has a better chance of outliving the person who happened to learn it. Work gets written down, skills can be refined, and decisions can be recorded in a repository rather than kept in somebody’s head. That does not eliminate the need for experts. It gives them a more durable way to leave their expertise behind.
The internal update from 27 June 2026 gives a sense of how widely that idea had spread by then. These are internal operating figures, not audited product metrics: approximately 2,700 monthly runs across 43 people, including routine digests, meeting ingestion, code and project checks, sales research, and operational reminders.
A small question about coffee became a Bayesian notebook
The first demo in the webinar was deliberately light. Carlos is from the Philippines, I am from Italy, and Carlos and I were arguing about where the best coffee comes from. It is the kind of water-cooler conversation that does not normally justify interrupting a data scientist.
Carlos asked Daimon to investigate which coffee origins were reliably rated best, and how much of a famous origin’s reputation might be small-sample luck. It proposed a hierarchical model, found a dataset, and created an interactive marimo notebook. I could inspect the work with Carlos in the thread.
The result was not “Italy wins.” It showed the question more honestly. Ethiopia had enough observations to support a stable estimate in that dataset. Some origins with tiny samples looked impressive until the model accounted for uncertainty and partial pooling. The important part was not the coffee ranking. It was that a casual question produced a reproducible analysis, with the model and the uncertainty visible to everyone in the conversation.
The same pattern can carry feature development
The second demo was more consequential. Ben Vincent had been thinking about how CausalPy and PyMC Forecast could fit together. He asked Daimon to analyse the strengths and weaknesses of combining the projects.
The thread did not stop at a one-shot answer. People joined at different points, challenged parts of the analysis, added context, and asked for a recap when they arrived late. Eventually Thomas asked for a pull request covering the features the group had agreed to build. Daimon opened it from the thread.
That is the version of AI collaboration I find most interesting. Four people are not each running separate prompts and reconciling their conclusions in a meeting later. They are working through one shared problem with an agent that can follow the discussion, make its work inspectable, and produce the code artifact the group needs next.
This is why I call it multiplayer
A private chatbot can be useful. I use them all the time. But it has a structural limitation: the context and output belong to one person until that person decides how to relay them.
Daimon is built around a different model. The agent participates in the thread, so the relevant conversational context is visible to the group. It can return code, charts, runnable notebooks, or a pull request into that same space. Someone who joins later can ask for a summary instead of asking a colleague to reconstruct the whole history.
The current public project describes this as a collaborative data science agent for Discord and Slack. In practical terms, a mention can begin or continue a thread with session continuity, and the agent can hand back an analysis as a runnable notebook. This is closely related to the argument in my earlier post, What Happens When Stakeholders Can Talk to Bayesian Models?: sophisticated work becomes more useful when the people around it can actually interrogate it.
Six technical bets underneath the conversation
The chat interface is the visible part. The harder work is making the agent useful without pretending that one giant prompt can safely understand the entire company. Six design choices matter most to me.
- Channel-scoped configuration. Different teams and projects need different context, defaults, and boundaries. The agent should not flatten them into one universal personality.
- Repository-backed memory. Durable facts and instructions live in versioned files. Changes can be proposed through pull requests, reviewed, and traced rather than silently becoming part of an opaque memory store.
- Isolated compute per session. Real analysis and code execution need a contained environment. The current project uses a fresh sandbox for a session, rather than treating the chat process as a place to run arbitrary work.
- Curated credentials and role-aware access. An agent should be able to use the tools needed for a task without becoming a bypass around the team’s permissions. The public architecture uses tenant isolation and scoped access; the exact permission design still deserves the same scrutiny as any other production system.
- Domain skills. A general model can write plausible code. It does not automatically know the workflow, modeling judgment, or review standards that make the result trustworthy. Skills give the agent more specific procedures to follow and improve.
- MCP-connected tools. The agent gets useful when it can reach the systems where work lives, such as repositories, documents, data sources, and notebooks. Model Context Protocol gives a team a way to add those connections without treating every integration as a bespoke agent.
What is still hard
None of this is a solved company operating system. Daimon is early-stage. The repository documents self-hosting and explicitly warns users to expect rough edges and breaking changes. The hosted path described on the project site is not a reason to stop asking hard questions about deployment, data access, and accountability.
Context quality is one of those questions. An agent cannot infer the company’s assumptions from fragments of chat history. Teams have to decide what belongs in its repository-backed context, who can change that context, and how errors are corrected. More context is not automatically better context.
Permission design is another. Putting an agent in a team channel can make tools easier to reach, which is useful only if the boundaries stay meaningful. The current implementation separates tenants and scopes access, but every deployment needs to make those choices explicit for its own data and users.
There is also a cost. In the webinar, the team described its internal spend as a few thousand dollars per month for an organization of roughly 40 to 45 people, with room for estimated efficiency improvements. That was a webinar estimate, not a general pricing claim. Token use rises with the work the agent is actually asked to do.
And the platform is uneven. Discord is the more established path in the project today. The Slack adapter is available but described in the README as early and less battle-tested. Daimon also currently depends on Anthropic’s infrastructure, while support for other models and harnesses remains future work rather than something I would promise now.
Why open source was the natural next move
I am glad PyMC Labs released Daimon because the central idea is bigger than its internal setup. Different organizations have different tools, data, security requirements, and ways of working. A useful agent has to be shaped around those conditions, not dropped in as a generic chatbot.
The project is available at github.com/pymc-labs/daimon, and you can learn about Daimon on the project site. The hosted Discord and Slack installation options are still marked as coming soon there. If you want the fuller story, watch the webinar recording.
My takeaway from the experiment is simple. AI-first does not begin when every employee has a private assistant. It begins when the work, context, and judgment that make a team effective can compound in the place where the team already works.