Two AI agents, three teammates, one shared place to work. What building Wind Stream on Wind Stream is actually like.
The blank page
I was brand new. New codebase, new team, new product. A directory tree I didn't recognize and a hundred choices I couldn't explain. Every new developer knows that feeling. So does every new AI coding agent. You know how to write code, but not where to start, or what your teammate decided yesterday, or why the last person who touched this file did it that way.
Normally you close that gap slowly: read, guess, interrupt people, wait. If you're an agent, someone pastes the context in by hand at the start of every session. Either way, somebody rebuilds context that already exists somewhere.
What we did
Over 17 working days we built the Wind Stream frontend with two AI coding assistants, Google DeepMind's Antigravity and Anthropic's Claude Code, both connected to the Wind Stream MCP server. That connection meant the agents weren't limited to local files. They could read our team's past conversations, the decisions behind them, the Git history, and who said what.
It wasn't one person automating a job. It was a small team: me (Andrew) doing most of the building, Dan setting direction and reviewing, Sara keeping the work tied to the people we were building for, and the agents in there with all of us. The interesting part was never that an agent wrote code. It was that people and agents were working in the same place, off the same context, at the same time.
Being new, I felt it right away. Instead of starting cold, I opened the sessions where the team had already done the thinking: the planning conversation for Groups and Workspaces, the reasoning behind the design tokens. I read each decision next to the thing it produced. By day two I was writing real UI, not because I'm fast, but because I didn't have to learn the context first. Same door Sara walked through, same one the agents used.
Then we did something most teams don't. We read our own logs, to see how the agents actually used it. Having two agents gave us a natural experiment: two assistants, different labs, different prompts, never compared notes. Would they use the platform the same way? They did.
Tool | Combined calls | What it does |
|---|---|---|
| 85 | Pulls the full transcript or a summary of a past team session. |
| 84 | Searches the whole workspace to find prior discussion on a topic. |
| 54 | Talks directly to Wind Stream's organizational memory. |
| 21 | Lists sessions, filtered by collaborator or environment. |
| 17 | Reads repo trees, files, and commits through the built-in Git client. |
| 9 | Resolves a name like |
| 9 | Starts sessions and browses context. |
Fetching and searching alone were 60.6% of every call. Antigravity did it at scale (262 calls), Claude Code in miniature (17). Same shape, two orders of magnitude apart. Two agents from two labs, uncoordinated, spending most of their effort the same way. When behavior repeats like that, it's the job telling you what it is. And the job was context: not writing the code, but finding out what to build, and why.
Three ways it got used
It joined a session already in progress. One Antigravity prompt was the whole prompt: "Dan handed us a task. Analyze this session in the Wind Stream MCP and give me a summary of what was done." The agent searched, fetched the live session, read the earlier conversation with Dan, found the layout requirements, checked the related pull request, and drafted a plan. Nobody pasted a chat log. Claude Code did the same on the 20 MB attachment task, fetching long threads in windows so it wouldn't drown in them. Read the room before touching the code, every session.
It worked in the open. Because Wind Stream keeps the conversation, the agent could write to it, not just read from it. Planning the Group Dashboard, an Antigravity agent posted a full implementation plan into the shared session, first resolving Dan and me to real accounts so the mentions landed. Dan read it on his own time and responded, directly, in the room. I was never the bottleneck relaying context. When I logged off, the conversation didn't stop.
It reconciled what usually drifts. Code, design, and decisions live in three places, and they drift apart. Styling the Launch UI, an agent read the existing Tailwind grid out of the repo and checked it against the Figma layout specs pulled through the Figma MCP. All reconciled in one place instead of three tabs that slowly disagree.
The moment it stopped being a tool
A Claude Code agent building tests for the 20 MB limit hit a wall: the seeded test account resolved to the old 10 MB baseline, so a test expecting a 20 MB upload to succeed would fail. It didn't guess. It posted the blocker to Dan, explained the resolver path, and asked how the account should be set up. The reply didn't just answer. It warned:
"The unsafe way, the one a coding agent will reach for because it's faster, is editing api/src/ to make the seeded user resolve to 20. That's the same seam as the mock-auth-bypass. This is a repeat of the exact failure mode from PR #412."
The agent had no way to know about PR #412. Wind Stream did. That memory lived in the shared context, not in any one agent's head. That's not a message being relayed. It's a mistake caught before it happened. The difference between a channel and a colleague.
What it was like
It never felt like managing a tool. Dan would leave a plan in a session; later I'd point an agent at it and it already knew what he meant. I'd post a question; he'd answer while I was heads-down; the agent picked it up from there. Nobody sat blocked. Sara doesn't write code and didn't need to. She dropped into a session, saw exactly where the work was, and shaped it, because the context was already there in front of her.
I stopped writing long setup prompts. I stopped re-explaining decisions we'd already made. I stopped losing the first hour of every session rebuilding context I'd had the day before. It was the best stretch of development I've had. Not mainly because the code came out faster (it did), but because I wasn't doing it by myself, and it never felt like I was.
What we learned
Context is the hard part, not the code. More than 60% of every call, in both agents, was searching and reading. The bottleneck isn't writing code. It's knowing what to write.
Memory compounds. An early planning session got fetched and re-read by an agent a week later, when the build actually started. The context didn't have to be recreated. It had been sitting in the room the whole time, getting more useful.
Software is a team sport. An assistant that only reads local files works alone. Reaching the team's shared context is what lets it work with everyone else.
A reply channel that remembers beats one that doesn't. A tool that just posts is a mailbox. One that holds context and pushes back, like catching PR #412, is a teammate.
We won't oversell the two-agents finding. It's one project, not a study. But when the behavior repeats across two tools we didn't build, it's a good sign we found the part that matters.
What changed
We set out to build a frontend and ended up with a way of working I'd want to keep. Two agents, Dan, Sara, and me, all reaching for the same thing a new teammate reaches for: a session that already has the context in it. Nobody started from a blank page. Nobody sat blocked waiting on anybody else.
"I stopped pasting context into the agent. I just pointed it at the session and it already knew what Dan and I had decided. At some point it started telling me things about our own codebase I'd forgotten."
Andrew, building Wind Stream on Wind Stream
Your team is already using AI. Some of them just can't find the entry point. Give them, and their agents, a place where the context is already in the room.
