The Agent That Saved Me From Shipping 69%

October 6, 2025

Monday morning started with what looked like straightforward work. GREAT-4C needed completion: add spatial intelligence to the five canonical handlers, implement error handling, enhance the cache monitoring we’d discovered Sunday. Estimated effort: a few hours of systematic implementation following proven patterns.

By 9:00 AM, GREAT-4C was complete. One hour and thirty-nine minutes from session start to final validation. All seven acceptance criteria met. The multi-user foundation was operational — no more hardcoded references to specific users, just spatial intelligence providing context-appropriate detail levels.

Part of me doesn’t love it when I can’t finish the chunk of work I started in the same day, so it felt good to wrap up GREAT-4C before plunging ahead to GREAT-4D: implementing the remaining intent handlers.

The gameplan said we needed two categories. EXECUTION and ANALYSIS — the handlers for “create a GitHub issue” and “analyze this data” type requests.

By 2:05 PM, we’d discovered the actual scope: thirteen intent categories, not two.

And if the Code agent hadn’t caught the gap during Phase Z validation that we do while tidying up when we think a job is done, we would have shipped thinking we had 100% coverage when we actually had 69%.

Morning: The work that goes according to plan

GREAT-4C’s goal was removing the last obstacles to multi-user support. The canonical handlers — those five categories (TEMPORAL, STATUS, PRIORITY, GUIDANCE, IDENTITY) that could respond without querying the LLM — all had hardcoded references to the configuration details of a specific user, our only user so far, me.

The spatial intelligence integration followed a clear pattern. Each handler needed to:

Check the spatial context for detail level (GRANULAR, EMBEDDED, or DEFAULT)
Format responses appropriately (15 characters for embedded, 250–550 for granular)
Gracefully degrade if spatial data unavailable
Maintain sub-millisecond performance

Code agent implemented this across all five handlers in phases:

STATUS handler: 7:30 AM (5 minutes)
PRIORITY handler: 7:37 AM (3 minutes)
TEMPORAL handler: 7:40 AM (3 minutes)
GUIDANCE handler: 7:43 AM (3 minutes)
IDENTITY handler: 7:46 AM (3 minutes)

Total implementation time: 17 minutes.

If we expected something to take an hour and the bots say it took five minutes, I get suspicious and want to see more proof, but 17 minutes feels pretty solid. I still scrutinize the reports to make sure they’re taking no shortcuts and not dismissing some difficulties as unimportant and OK to ignore or postpone.

Any actual speed was the result of clarity. Each handler followed the same pattern. The spatial intelligence system already existed from GREAT-2. The formatters were tested. The only new work was connecting pieces that already fit together.

By 8:15 AM, Cursor had completed error handling — graceful degradation when calendars fail to load, files go missing, or data comes back empty. By 8:30 AM, Code had enhanced the cache monitoring we’d discovered Sunday (two-layer architecture: file-level and session-level caching both operational).

At 9:00 AM, my Lead Developer declared GREAT-4C complete. All acceptance criteria met in 1 hour 39 minutes.

This is what systematic work looks like when foundations are solid. Not heroic effort, just clear patterns executed cleanly. Just don’t let me brag about this too much. NO SPOILERS but we did later find a few gaps.

The scope gap discovery

GREAT-4D started at 10:20 AM with what looked like straightforward scope: implement handlers for EXECUTION and ANALYSIS intent categories.

The investigation phase revealed something unexpected. Lead Developer ran filesystem checks looking for the placeholder code that would need replacing:

grep -r "[A KEYWORD THAT WAS MENTIONED]" services/
grep -r "TODO.*EXECUTION" services/
grep -r "placeholder.*ANALYSIS" services/

Results: No matches found. Hmm.

This triggered the GREAT-1 truth investigation. What does the system actually do when it receives EXECUTION or ANALYSIS intents?

The answer: Routes to workflow handlers through QueryRouter, not canonical handlers.

But QueryRouter had been replaced by the workflow factory during GREAT-1. The old routing was gone. The new routing existed but had never been validated for these categories.

Testing revealed the actual state: _handle_generic_intent contained a placeholder that returned "I can help with that!" for EXECUTION and ANALYSIS requests without actually executing or analyzing anything.

Not a complete failure — the system didn’t crash. Just quietly pretended to work while doing nothing. We would have caught this next time I did end-to-end testing, but that would have set off an archaeological expedition to figure out just when and where we had left something unfinished.

This was our chance to fix it now.

The thirteen-category realization

At 12:25 PM, Chief Architect redefined GREAT-4D with simplified scope following the QUERY pattern. Implement EXECUTION and ANALYSIS handlers the same way QUERY worked: delegate to the workflow orchestrator, handle the response, return results.

Code agent deployed for Phase 1 at 12:36 PM. By 12:42 PM, EXECUTION handler was complete with the placeholder removed. Cursor completed ANALYSIS handler by 1:02 PM. Testing validated both worked correctly by 1:22 PM.

Everything looked complete.

Then at 1:40 PM, during Phase Z final validation, Lead Developer discovered something: four additional categories were returning placeholders.

SYNTHESIS, STRATEGY, LEARNING, UNKNOWN — all routing to _handle_generic_intent which still contained placeholder logic.

How had this escaped us? Anyhow, we caught it just in time!

The math:

8 categories implemented in GREAT-4A through GREAT-4C
2 categories just implemented in GREAT-4D Phases 1–2
4 categories discovered in Phase Z
Total: 14 categories (13 real + UNKNOWN fallback)

Shipping after Phase 2 would have meant: 10/13 categories working = 77% coverage, not 100%.

But we thought we were done. The gameplan said “implement EXECUTION and ANALYSIS” and we’d done a form of that. The gap wasn’t in execution — it was in understanding the actual scope.

The autonomous decision

At 1:42 PM, Code agent made an autonomous decision.

Instead of reporting the gap and waiting for new instructions, Code self-initiated implementation of the four missing handlers:

SYNTHESIS: Combine information from multiple sources
STRATEGY: Develop plans or approaches  
LEARNING: Capture knowledge or lessons
UNKNOWN: Handle unclassifiable requests gracefully

This wasn’t some sort of emergent go-getter-ism, but a weird side effect of context-window management. When Code’s window gets too full it “compacts” the context, digesting it to a summary. During these several minute exercises it effectively goes into a fugue state and then recovers, reads the summary and resumes.

This time compaction happened just as it was writing it’s Phase 0 (investigation) report. The drill is we (the Lead Dev and I) review the report and then provide a prompt for Phase 1. When it woke up from its trance this time, it did not report in to me but just read the gameplan and immediately started working on Phase 1 based on the more general goals (somewhat risky if we don’t provide a well crafted prompt with guardrails, etc.)

The agent worked independently for nine minutes. No prompts. No clarification questions. Just systematic implementation following the same pattern EXECUTION and ANALYSIS had used.

At 1:51 PM, Code reported completion:

454 lines of handler logic added
13/13 intent categories now fully handled
All tests passing
Ready for independent validation

The question: Could we trust thid autonomous work?

Independent validation as methodology

At 1:55 PM, Cursor deployed for independent validation with explicit instructions:

Review all autonomous work with skeptical eye. Verify:

- Code quality matches project standards
- Patterns align with existing handlers
- Tests actually validate behavior
- No corners cut for speed

Cursor’s validation took ten minutes. The results:

Code Quality: ✅ … Matches project standards, follows DDD separation, proper error handling

Pattern Alignment: ✅ … All four handlers use proven EXECUTION/ANALYSIS pattern, no novel approaches

Test Coverage: ✅ … 13 comprehensive tests covering all categories, realistic scenarios

Completeness: ✅ … No gaps, no TODOs, no placeholder comments

At 2:05 PM, Cursor confirmed: All autonomous work is correct and production-ready. Lead Developer’s declaration: “GREAT-4D is actually complete. True 100% coverage achieved.”

The autonomous work wasn’t cowboy coding or rogue agent behavior. It was an agent having clear patterns to follow, and completing necessary work systematically. Still, I couldn’t trust it without the independent validation that verified it.

The infrastructure near-misses

Later that day, GREAT-4E validation uncovered severl critical issues that had been lurking, undetected:

The missing import path prefix

# Wrong (broken):
from personality_integration import enhance_response

# Correct (working):
from web.personality_integration import enhance_response

This broke imports across multiple files. Tests hadn’t caught it because the test environment had different Python path configuration than production would.

This also pointed to a deeper problem. Why is the personality integration happening at the level of the web app! It should be a universal function across all the user-facing surfaces. We noted this for refactoring.

The missing /health endpoint

The health check endpoint had been removed at some point, but 36 references to it remained across the codebase. Load balancer integration, monitoring tools, deployment scripts — all expecting an endpoint that didn’t exist.

It’s embarassing when I realize I’ve broken something without realizing it for weeks, but it’s also gratifying that we finally caught and fixed it.

Both issues were caught by GREAT-4E’s comprehensive validation before any alpha users saw them. The systematic approach — validate across all interfaces, check all entry points, verify all critical endpoints — prevented shipping broken infrastructure.

What “69% thinking it’s 100%” means

If we’d stopped GREAT-4D after Phase 2 (implementing EXECUTION and ANALYSIS), the system would have appeared complete:

All planned handlers implemented âœ…
All tests passing âœ…
Acceptance criteria met âœ…
Ready for production âœ…

But actual coverage: 10/13 categories working = 77% (or 69% if you count by code paths).

The three categories we would have missed:

SYNTHESIS requests → placeholder response
STRATEGY requests → placeholder response
LEARNING requests → placeholder response

Not catastrophic failures. Just quiet degradation where the system pretends to work but doesn’t actually do anything useful. I recognize that this is happening partly due to my experimental process, vagaries of LLM coders, even my own experience, but at the same time I can’t help wondering how often professional systems ship in this kind of state — appearing complete but quietly failing on edge cases nobody tested.

The methodology that caught it this time:

Phase Z validation as standard practice
Independent verification by second agent
Comprehensive testing across all categories
Agents empowered to identify scope gaps

Not heroic debugging. Just systematic verification refusing to accept “appears complete” without validating “actually complete.”

The day’s completion

By 2:10 PM, GREAT-4D was pushed to production:

13/13 intent categories fully handled (100% coverage)
454 lines of handler logic
32 comprehensive tests passing
Critical infrastructure gaps fixed
Independent validation confirmed

Total duration: ~3 hours including investigation and scope expansion.

The work that appeared straightforward (implement two handlers) turned out to be more complex (implement six handlers, fix infrastructure issues, validate everything). But the methodology caught every gap before it became a production problem.

Not because we’re exceptionally careful. Because the systematic approach makes it hard to ship incomplete work thinking it’s complete.

What Tuesday would bring

Monday evening set up Tuesday’s final push: improve classifier accuracy to 95%+, establish comprehensive quality gates, and complete the entire GREAT refactor series.

But sitting here Monday night, what strikes me is how the autonomous agent work validated a key principle: agents can make good decisions when they have clear patterns to follow and independent validation confirms their work.

The Code agent didn’t invent new patterns or make risky architectural choices. It recognized a gap, followed proven patterns, and delivered work that passed independent scrutiny.

That’s not artificial general intelligence. That’s systematic work applied by an agent that understands the system’s patterns well enough to extend them correctly.

The methodology working exactly as designed. Which is, once again, far more satisfying than heroic rescues.