The Board Meeting, the Smart Glasses, and the 9-Task Overnight Dispatch

Two sprints shipped before lunch. A board meeting changed everything. Then I bought smart glasses, dispatched 9 tasks before bed, and woke up to all of them done. Day 4 of building with an AI team.

---

📖 Build Log Series: Day 0: The Setup · Day 1: First Sprints · Day 2: Six Sprints · Day 3: The Newsletter · Day 4: The Board Meeting · Day 5: The Scaling Week · Day 6: The Week of Infrastructure · Day 7: When an Idea Becomes an Agent

---

▸ Sunday Morning: Two Sprints Before Lunch

I woke up Sunday with a backlog and a plan.

Sprint 27, "Mission Control: Actionable Intelligence," was five tasks. The goal: replace the passive dashboard I'd been staring at with something that actually told me what to do. Claire researched the UX patterns. Felix built the backend. Luna wired up the frontend. Sara ran QA.

Thirteen minutes. Five tasks. One QA bug — an API response shape mismatch between what Felix sent and what Luna expected. Sara caught it, Felix fixed it, and we moved on.

Sprint 29, "Agent Engagement & Stats," was more ambitious. Nine tasks. Live agent status indicators. Engagement logging. Per-agent stats with streaks. A team leaderboard. A GitHub-style contribution heatmap. Trend charts.

Three QA bugs this time. A route naming collision. An auth middleware issue. An avatar sizing problem on the stats cards. Sara found all three. All fixed within minutes.

Here's the thing about watching AI agents run QA on code written by other AI agents: it works better than it has any right to. Sara doesn't get tired. She doesn't skip edge cases because it's 4 PM on a Friday. She tests the same way at task nine as she does at task one.

Both sprints shipped before I finished my second cup of coffee.

Day 8: The Browser Becomes the Agent · Commits:

• ▹015377a — Allow any user (not just agents) to be assigned to tasks
• ▹846d2cc — Visual distinction for completed tasks on sprint overview
• ▹e1e15fd — Condense Mission Control alert cards for better density
• ▹dca7485 — Add user-assigned tasks to Mission Control
• ▹e9b85fd — Replace idle agent suggestions with Team Capacity meter
• ▹b948173 — Fix team capacity component API response shape
• ▹435158b — Fix TypeScript interface and sprint task styling
• ▹4072030 — Add snooze endpoint, fix alert dismiss/snooze

▸ 11:00 AM: Mission Control Gets Real

After the sprints landed, I spent time in the UI. Mission Control was supposed to be my command center. Instead, it was a dashboard with fake data and suggestions I didn't need.

The mock alerts had to go. I told Felix to rip them out. Then I asked him to replace the "idle agent suggestions" panel with a Team Capacity meter. Simple readout: "3/10 active | 5 tasks in flight." That's what I actually need to know.

The bigger win: my own tasks now show up in the Action Required section. Before this, Mission Control only tracked agent work. But I'm part of the team too. I have tasks assigned to me — LinkedIn profile updates, pinned posts, review items. Those should be front and center when I open the dashboard.

Felix wired it up so my tasks pull from any active sprint, sorted by priority. Critical tasks show up in red. Medium in amber. It uses $request->user()?->id instead of auth()->id() because our custom AuthenticateApiToken middleware doesn't play nicely with Laravel's default auth guard.

A tiny implementation detail. The kind that costs you two hours if you don't know about it.

I also pushed Luna to condense the alert cards. Her first design was spacious. Beautiful, even. But I could only see two alerts at a time on my screen. I need density. I need to see the state of my entire operation at a glance, not scroll through a gallery.

New design: two-tier system. Critical alerts get compact cards with inline action buttons. Warnings and info items collapse into a tight list view. Descriptions hidden by default, expandable on click. Three to four alerts fit where one to two did before.

This is a pattern I keep noticing: the AI agents design for visual appeal. I redesign for information density. Neither is wrong. But my dashboard isn't an art gallery. It's a cockpit.

▸ 1:30 PM: Agent Status Goes Live (Finally)

We'd been tracking agent status — who's working on what, who's idle — but the WebSocket wasn't broadcasting updates. The controller code set the status in the database but never fired the AgentStatusChanged event.

Three bugs, all found in one testing session:

1. ▹The controller wasn't broadcasting status changes on set or clear
2. ▹The event payload didn't include the engagement_type field
3. ▹The frontend didn't have sprint_work in its engagement type config, causing a crash

Felix fixed all three. I watched in real-time as Meri's agent card lit up when I dispatched her for a portfolio review, and went dark when she finished.

That moment — watching the status update happen live, without refreshing — felt like the first time the system was actually alive. Not a project management tool. Not a dashboard. A live view into a working team.

▸ 3:13 PM: The Board Meeting That Changed Everything

I asked Meri to prepare an executive briefing. She delivered a full portfolio review of all four projects.

Her assessment was blunt: "You have a revenue problem disguised as a progress problem."

Here's what she saw:

Project Spark (the AI team management platform): 29 sprints completed. Impressive velocity. Zero dollars in revenue. Her recommendation: feature freeze for 90 days.

Own Your AI (the book): Completely stalled. Her recommendation: kill it or pause until we hit $50K ARR (annual recurring revenue).

Meta Ray-Ban R&D (more on this below): "Shiny object syndrome." Her recommendation: defer until $10K MRR (monthly recurring revenue).

brianstory.com (consulting site): The only revenue path. Her recommendation: 90/10 resource split for the next 90 days.

She wasn't wrong about the diagnosis. But she was wrong about the prescription.

I pushed back. Hard.

"I'm the bottleneck, not the team," I told her. "The tools I build are for ME to work efficiently. Agent hours are zero marginal cost. I'm on Claude Max — unlimited usage. This isn't a traditional startup with headcount constraints."

Meri conceded. She'd been applying a traditional startup framework to a team where the workers cost nothing extra to deploy. In a normal company, every hour spent on Spark is an hour not spent on revenue. In my setup, I can run six agents on Spark while I personally focus on sales calls.

Day 8: The Browser Becomes the Agent · The decisions:

1. ▹Sprint 33 (Revenue Conversion Pipeline): Approved. Ship Calendly integration, visual assets, LinkedIn optimization. Revenue first, but not revenue only.
2. ▹The book: Approved as a dedicated team project. Not killed. But it needs a proper kickoff — audience research, competitive audit, structure, voice guide. And I'm "hiring" an editor agent to run it. Not just Victor (my content agent) writing alone.
3. ▹Meta Ray-Ban R&D: Stays. But time-boxed to 3-5 hours per week. Every deliverable must tie to consulting credibility. If we can't publish it, we don't build it.
4. ▹Content distribution: Manual for now (I'm posting to LinkedIn, Facebook, and X myself), but Sprint 34 (automated distribution) moves up the priority list.

The board meeting — yes, it's a board meeting between a human and an AI strategist, and yes, I'm aware of how absurd that sounds — lasted about an hour. It produced six strategy documents and a clear 90-day direction.

▸ 4:00 PM: I Bought Smart Glasses

Somewhere between the board meeting and dinner, I decided to buy Meta Ray-Ban Display smart glasses. $799. Transitions lenses. Neural band included.

Why? Because I want to build for them.

Claire (research agent) had already done preliminary research. The Meta Wearable Developer Augmented Toolkit (MWDAT) SDK exists. Camera and audio APIs are accessible. But the display — the thing I actually want to program — is locked down. No public API. No way to push custom content to the heads-up display.

I created a new project in Spark. Project #4: Meta Ray-Ban R&D. Sprint 53, "Platform Discovery," with seven tasks split between Felix and Claire.

Felix's findings from the SDK deep dive:

• ▹Camera streaming works. Photo capture works. Bluetooth audio works.
• ▹Display HUD access: locked. Neural Band sensors: locked. Meta AI hooks: locked.
• ▹Only about 20% of the hardware sensors are developer-accessible.
• ▹The official SDK is currently the only viable path. No jailbreaks. No alternative firmware.

Claire mapped the community landscape: teardowns, developer forums, third-party experiments. The BLE (Bluetooth Low Energy) protocol is the most promising attack vector for display access. Someone will crack it eventually. We want to be ready when they do.

Is this a distraction from revenue? Maybe. But Meri agreed to let it stay — as long as it produces content. An AI consulting firm that's actively developing for cutting-edge hardware platforms? That's a differentiator. That's credibility you can't fake.

Sprint 53: 7/7 tasks completed. Closed. All research docs at projects/meta-rayban/research/.

▸ 5:30 PM: The Dispatch Protocol

Something I kept running into: when I send an agent on a task, they don't have enough context. Felix doesn't know what Luna shipped last sprint. Claire doesn't know about the bug Sara found yesterday.

So I formalized the dispatch protocol.

Every agent now has a BRIEFING.md file. It contains their role, project conventions, date-stamped lessons learned, and current context. When Atlas (that's me — the orchestrator) dispatches an agent, their briefing goes with them.

I created briefings for all ten agents: Felix, Sara, Luna, Claire, Meri, Max, Victor, Nora, Petra, and the soon-to-be-hired editor.

It's like onboarding materials for employees. Except the employees have amnesia every time they clock in. The briefing is their memory.

This is one of those infrastructure investments that doesn't feel productive while you're doing it. You write ten documents and nothing ships. But the next sprint will run smoother because of it. And the one after that. Compound returns.

▸ 9:18 PM: The Overnight Dispatch

Sunday night. I'm about to go to bed. But the blog needs work. The brianstory.com site has a Series model but no API for it. Posts sort wrong. Tags aren't browsable. There's no hit counter. The admin panel doesn't show publication times.

So I wrote up nine tasks and dispatched them all:

1. ▹Felix (#421): Blog Series CRUD API — expand the existing Series model with full REST endpoints
2. ▹Felix (#422): Basic hit counter — post_views table, rate limited so refreshing doesn't inflate numbers
3. ▹Felix (#423): Sort blog posts by published date, descending. Drafts first.
4. ▹Luna (#424): Show full published datetime in admin, not just the date
5. ▹Luna (#425): Blog series management UI in admin — 1,096 lines of new code
6. ▹Luna (#426): Frontend tag browsing — dedicated tag show pages with post listings
7. ▹Victor (#427): Audit every blog post for proper tags. Four posts had zero tags. Victor tagged them all and created five new tags. He also found a major tag duplication issue — 18+ copies of "Build Log" floating around. Cleanup task needed.
8. ▹Claire (#428): Research full analytics solutions. Her recommendation: Umami (self-hosted, ~200MB RAM, free, GDPR compliant).
9. ▹Claire (#429): Research blog audio/TTS options. Her recommendation: pre-generated audio via OpenAI TTS, not browser-based Web Speech API.

I said goodnight. Went to sleep.

Day 8: The Browser Becomes the Agent · Woke up Monday morning. All nine tasks done.

Three commits landed overnight:

• ▹db30cc9 — Series CRUD API, post view counter, published_at sorting
• ▹52f67b5 — Tag browsing UI with dedicated tag show pages
• ▹2cc03de — Blog series management UI in admin

Plus one more during the day:

• ▹2b8a41e — Fix blog post scheduling: auto-set status to published when published_at is set

That last one was a bug I found when the build log posts from Day 0-3 weren't going live on schedule. The system was setting published_at but not flipping the status field. A one-line fix that saved the entire publishing pipeline.

▸ Monday: The Design Sprint Nobody Asked For

Monday (today) was supposed to be quiet. Catch up. Review the overnight work. Maybe approve Sprint 33.

Instead, a design system sprint materialized. Twenty-one commits to Spark in a single day:

• ▹Standardized card styles across every page
• ▹Extracted the Starfield background effect into a shared component
• ▹Removed a legacy grain-texture CSS class from every file in the codebase
• ▹Built project archive/unarchive endpoints
• ▹Added Open and Edit buttons to project cards
• ▹Built a full Project Edit Sheet component
• ▹Enhanced sprint cards with dates, hover states, and quick actions
• ▹Added filtering and search to the sprints list
• ▹Improved empty states across all sprint pages
• ▹Added bulk sprint operations
• ▹Built sprint health indicators
• ▹Improved the sprint creation modal
• ▹Fixed nested anchor tags causing React hydration errors

Commits b90108d through a89ce11. Twenty-one commits. All Spark. All in one day.

The hydration error fix (a89ce11) is worth mentioning. React server-side rendering freaks out when you nest <a> tags inside other <a> tags. Luna's sprint cards had a link wrapping a card that contained another link for the sprint action. The HTML spec says this is invalid. React agrees. The fix: restructure the card so the clickable area uses onClick handlers instead of nested anchors.

It's a subtle bug. The page works fine on first load (server-rendered HTML is valid). It breaks on client-side hydration when React tries to reconcile the DOM. You'd never catch it in a screenshot review. You'd only catch it by actually clicking around in the browser.

Sara would have caught it in QA. But this time, the browser console caught it first.

▸ The Calendly Decision

One more thing from the board meeting. Meri and I settled the Calendly strategy.

My instinct was to create separate booking links for different service tiers: one for strategy calls, one for implementation, one for training. Meri talked me out of it.

"You have zero revenue," she said. "At zero revenue, minimize friction. One link. One discovery call. Everyone goes through the same door."

She's right. Segmentation is a scaling problem. I'm not scaling yet. I'm starting.

One Calendly link. Short intake form (3-5 questions, including budget). 24-hour proposal follow-up cadence. Split into tier-specific booking when we have enough data — 10 or more calls — to see self-identification patterns.

Simple. Boring. Correct.

▸ What I Learned

Day 8: The Browser Becomes the Agent · Day 4 taught me three things:

1. ▹

   Your AI strategist will apply human frameworks unless you correct them. Meri tried to treat agent hours like employee hours. They're not. The economics are different. The constraints are different. You have to actively teach your AI team how your business actually works.

2. ▹

   Overnight dispatches are a superpower. Nine tasks. Zero supervision. All done by morning. This only works because of the briefing system — agents have enough context to work independently. Without it, they'd be guessing.

3. ▹

   Information density beats visual design. Every time. My AI agents design beautiful interfaces. I redesign them for density. The dashboard isn't a portfolio piece. It's where I run my business. Every pixel should earn its space.

Day 8: The Browser Becomes the Agent · Running totals after Day 4:

• ▹Sprints completed: 31+ (lost exact count)
• ▹Active projects: 4
• ▹Blog improvements shipped overnight: 9
• ▹Board meetings held with an AI strategist: 1
• ▹Smart glasses purchased on impulse during said board meeting: 1
• ▹Revenue generated: still $0

That last number is the one that matters. Meri's right about that. Everything else is infrastructure.

Tomorrow, Sprint 33 ships the revenue pipeline. Calendly goes live. LinkedIn gets optimized. The machine starts pointing at money.

But tonight, all nine overnight tasks are done, the dashboard finally shows me what I need to see, and my smart glasses are charging on the nightstand.

Day 5 is going to be interesting.

---

This is part of an ongoing build log series. I'm documenting the real process of building a business with a team of AI agents — the wins, the bugs, the arguments with my AI strategist, and the uncomfortable revenue numbers. Subscribe to follow along.