Building an AI teammate for our own team: what we learned

You can build a basic AI teammate in a weekend: pull recent GitHub and Slack activity, hand it to a model, and have it write a morning note. The first version will look convincing. The hard parts show up in week two, when decisions get reworded, the note gets long, and you have to decide what the assistant should stay quiet about. We built one for Liouville Labs' own team, and this is what we would tell you before you start.

Why did we build one on our own repos?

Our problem is the one this blog keeps coming back to: AI-native teams create context faster than people can sync, manage or remember it. Liouville Labs runs about a dozen products with agents writing most of the code, and one product shipped 200+ PRs in two weeks. Decisions happen in Slack threads, plans change mid-week, and the rituals we grew up with (standup, weekly status, the retro) were built for a slower rate of change.

So we built the thing we wanted to read each weekday morning. In the 30 days to October 3, 2026, Biddle's own repository had 367 non-merge commits on main, and every one carried a Claude co-author trailer. That is our own git history, not something Biddle classifies. It means we were building a tool for tracking fast-moving agent work with a codebase that moves the same way.

As of October 3, 2026, 16 products are set up in Biddle on our own team, each with at least one GitHub repository, and 11 also have Slack channels. Treat everything below as notes from one team, not benchmarks.

What does a weekend version look like?

The skeleton is simple, and it is worth building if you want to learn the shape of the problem:

1. Read merged PRs, reviews and CI status from GitHub for the repos you care about.
2. Read the Slack channels where decisions happen.
3. Ask a model to write a short note for you: what needs a decision, what changed, what is worth a look.
4. Post it to your DM every weekday morning.

That is roughly the structure of our own leader briefing (see the sample briefing): a section for what needs you, a section for what changed since the last one, and a short list of things worth a look. If you want a template for the output itself, we published one in the daily status update template.

If you stop here, you have a summarizer. It will tell you what happened. It will not reliably tell you what you need to act on, and that gap is where most of the work is.

What broke when we ran it on our own repos?

These are the lessons we would pass on. None of them is about the model. They are about the records and the delivery around it.

Decisions do not hold still

The first instinct is to store decisions as write-once notes. Our record says otherwise. Between September 1 and October 3, 2026, Biddle's record holds 448 decisions on our own team: 374 active, 13 superseded by a later decision and 61 archived. As of October 3, there were 444 text revisions to stored records, and 200 of them rewrote a decision statement.

The contrast is the useful part. The wording of a decision gets revised far more often than the decision gets replaced. If your store treats every new message as a new decision, it fills with near-duplicates. If it treats every message as an edit, it loses history. You need a status (active, superseded, archived) and a link back to the thread that produced each version. Our decision log template shows the minimum columns.

The unit of delivery is the reader, not the source

Our first delivery was per product. On September 30 and October 1, Biddle delivered 15 product briefings plus 2 "no changes" summaries. From October 2, it sends one combined morning briefing per recipient. When you have many products, a message per product multiplies the number of things someone has to open, and a "no changes" note is still a note. Design the output around one person's morning and let the sources feed it.

Uncertain activity has to go somewhere

Not every commit or thread maps cleanly to a piece of work. In Biddle, activity that cannot be tied to a workstream with enough confidence (below a 0.7 gate) is stored as unclassified and kept out of briefings and nudges. A wrong claim in a briefing costs more trust than a missing one, so we chose silence. The trade-off is real: the current briefing does not show a count of what was left out, so the reader cannot see how much was held back. If you build your own, decide up front whether you want that visibility.

A PR description is not the code

Agent-written PR descriptions are useful signals of intent, but they are not the diff. Biddle reads the title, description, commit messages, changed-file list, reviews, CI status and a diff excerpt of about 6 KB per PR, not the whole codebase. That is enough to say what a PR set out to do. It is a thin basis for claiming that the code matches a decision. This is why we describe plan drift as something Biddle is learning to flag, not something it does today. Our plan drift post has a manual check you can run instead.

Do not wait for users to correct it

Biddle lets a teammate reply "Correction:" in the briefing thread, and later briefings treat that as a standing instruction. As of October 3, 2026, no corrections had been recorded from members. That does not tell us the output is right. It tells us people were not correcting it yet. If you build your own, plan to review the output yourself, early and often, rather than waiting for complaints.

What should you build first?

This table orders the work by what protects trust, not by what is easiest to demo.

Part of the job	Build it first because	What goes wrong if you skip it
Evidence links on every claim	A reader can check a statement in one click	The note becomes a thing you have to fact-check
Decision status (active, superseded, archived)	Wording changes far more often than decisions get replaced	Duplicates pile up and old calls look current
One output per reader	Fewer messages to open	People mute it within days
A rule for uncertain activity	Silence is cheaper than a wrong claim	Confident mistakes in the morning note
Read-only access	Nothing it does can touch your repos	Trust questions block adoption
A review habit for the output	Users rarely report errors on their own	Mistakes stay in the record

On access, Biddle's GitHub App is read-only: it does not comment on PRs or write code, and it posts only in DMs, its own #askbiddle channel, and threads where someone asks it. We would start there. A tool that only reads is easier to trust and easier to turn off.

Should you build it or wait?

Build it if the goal is to learn how your own team's context moves. A weekend version will show you where your decisions live and how much of your week goes to reassembling state. That knowledge is useful whatever you end up running. Keep the first version narrow: GitHub and Slack are enough. We ran on those two alone before adding Linear and Notion.

The cost is in the tail: keeping decision records current, tuning what to leave out, handling questions in Slack (our Q&A has answered 24 questions since it went live on October 1, 2026) and permissioning answers correctly. Those parts keep needing attention long after the demo works.

Biddle is in early access and runs every weekday for our own team: the leader briefing, a note for each teammate with a seat, the team briefing in #askbiddle, and Q&A in Slack. We are onboarding a few product teams now, setting each one up with them. You can see where it stands on the home page. If you are weighing whether to build your own AI teammate or try ours, you can request early access and we will set it up with you.

Common questions

What should a first version leave out?

Leave out anything that writes. Start with reading GitHub and Slack and posting to one DM, then add sources only when you can name the decision they would change.

Can the model just read every PR and summarize?

It can, and the result is a longer feed. The useful output is a short list of what needs a human, with links to the PRs or threads behind each item. For the volume problem, see what to track when agents open too many PRs.

Do you need Linear or Notion connected to start?

No. GitHub and Slack are enough to run a morning briefing; we ran our own team on those two first. Biddle reads Linear and Notion too when you connect them.

Read next

• What is an AI teammate for product teams?: the definition and how to evaluate one before you build or buy.
• Keeping an AI-native product team on the same page: the shared record and weekly rhythm that any version of this depends on.
• Plan drift: when a merged PR quietly undoes a team decision: a manual check for the problem a DIY build will hit first.