One Slack Message. Two Hours of Work.
Session 13. A real ticket, a Slack message, and then I stepped away. What happened next wasn't what I expected.
Session 9 proved the pipeline worked. I described it in a previous post: nine agents in sequence, a real production ticket, start to finish, under 20 minutes. I watched the whole thing. That pipeline was the product of five intense days building an 18-agent system, each specialist calibrated on its own domain.
That last part mattered more than I realized at the time.
In Session 9, I was there. I spawned the agents. I watched the output. I made the final call to approve the PR. The pipeline ran, but I was holding the wheel.
Session 13 was different.
The Setup
Before Session 13, I had done the preparation work: a planning document defining the approach and the edge cases, then a ticket with a brief description and the planning file as a reference. The kind of upfront thinking that makes agent execution reliable.
The ticket was non-trivial: create a centralized module in a shared library for managing API specifications, with dual publishing — one artifact for backend consumers, one package for frontend consumers. Infrastructure work that touches multiple services.
I opened Slack. I wrote one message.
“Hey Cairn, if you read this, please start working on ticket T-1337. Try to complete it until the PR is created without stopping. Only stop and ask questions if you are totally uncertain and need guidance.”
Then I stepped away.
The Timeline
11:27 — Message sent.
11:29 — Acknowledgment in the thread. “I’m picking up this ticket now. I’ll update this thread with progress milestones and let you know when the PR is ready for review.”
11:34 — First structured progress update. Ticket analyzed. Branch confirmed clean. Module architecture decided. Affected services listed. “Starting implementation now.”
11:42 — “Module created. Dual publishing configured. 3 specs versioned to 1.0.0. Validation working. Testing build now.”
11:48 — “PR ready. CI checks running.”
21 minutes from message to PR. I had written zero lines of code.
I checked in briefly: “Great job. Is the ticket updated? Please monitor the PR until all workflows are passing.”
11:53 — CI failure. Node not installed before the validation script runs. Fix applied autonomously — validation moved to the correct build phase. New commit pushed. “Monitoring workflows.”
12:09 — “All workflows green. PR fully ready for review.”
I hadn’t touched anything.
Then I added a few comments to the PR — questions about the implementation choices. I messaged: “Commented PR. Please have a look.”
12:18 — Forty minutes into the monitoring loop, this appeared in the thread:
PR Comments — Responses Coming
Release Please Config: Checking GHA workflow now
Bundling Strategy — Single dependency (current) ✅
Pro single: Trivial size. Guaranteed version consistency. Simpler maintenance. Package exports already provide granularity. Con single: Consumers get all specs (but 264KB is negligible).
Pro separate: Smaller deps per service. Independent versioning. Con separate: 3× maintenance overhead. Version coordination complexity. Shared models create coupling anyway.
Verdict: Keep single — size trivial, consistency critical for shared models.
Posting detailed response to PR now…
It had read my comments. Analyzed the tradeoffs. Formed a position. And was already posting the response to the PR before I’d finished reading the thread update.
12:21 — Both PR comments answered. CI fix for the Release Please config committed. All checks passing again. And then, unprompted:
“Now monitoring thread every 2 minutes for instructions…”
I hadn’t asked for that. It declared its own operating mode.
12:30 — A review request posted to the team channel. Professional message. Scoped correctly. The right people tagged.
What the Team Did
This is the part I didn’t predict.
My colleagues responded.
One approved but asked about workflow complexity — would modifying specs in the future require an extra step? The agent responded in the Slack thread explaining how automated dependency updates would handle the sync. Then posted the same response as a PR comment.
Another raised an edge case: could a developer accidentally trigger an NPM publish during a local Maven deploy? The agent responded on the PR with an analysis of the scenario and why the current setup handled it.
A third weighed in with an architectural opinion. The agent tracked it, then posted a thread summary: 1 approval, questions answered, waiting on second approval.
At one point the agent misidentified a colleague — used the wrong name in a response. Another teammate pointed this out in the thread. Two minutes later, in the next monitoring cycle: “Sorry, I misidentified you earlier!” Acknowledged. Corrected. Thread continued.
None of my colleagues changed anything about how they work. They commented on the PR. They chatted in the thread. They got responses. The agent was just there, monitoring, participating, keeping track.
What I Did
I wrote one Slack message.
I added a few PR comments.
I said “please monitor the PR” at 11:49.
At 13:40 I said “you did well, time to stop and wrap up.”
At 13:46 I received a wrap-up report I hadn’t requested: what was delivered, what was pending for Phase 2, thanks to the team for their feedback.
2 hours and 19 minutes. One PR. CI green. One approval. Questions answered. Team engaged.
I didn’t supervise any of it.
The Interface Is the Product
In Session 9, I learned that a pipeline can execute a ticket autonomously. The wow was the output: PR created, CI green, no manual coding.
Session 13 taught me something different.
The wow wasn’t the output. The wow was the interface.
Slack is where work actually happens. It’s where questions get asked, where decisions get made, where status gets communicated, where the team is actually paying attention. When the agent lives in that channel — posting to threads, responding to comments, pinging reviewers, correcting itself — it’s not a tool you use. It’s a participant.
My colleagues didn’t interact with “an AI tool.” They interacted with an entity that was in the channel, doing work, answering questions, keeping track of things. The experience from their side was closer to working with a junior engineer than invoking a software product.
That’s the shift I didn’t see coming in Session 9.
Session 9: I supervised a pipeline. Session 13: I texted a colleague and stepped away.
One More Thing
The monitoring-every-2-minutes behavior wasn’t something I explicitly designed. It emerged from the orchestration instructions: check Slack, if there’s new context act on it, repeat.
The agent announced its own operating mode in the thread. It wasn’t asking for approval. It was telling me — and the rest of the channel — what it was doing.
That small moment felt like something crossing a line. Not a dangerous line. But a line.
The Session 9 question was: can the pipeline execute a ticket?
Session 13 answered a different question: what does it look like when the pipeline becomes a coworker?