AI Systems Architecture in Seattle: My Approach to Multi-Agent Workflows
I live in Magnolia, Seattle, right across from Discovery Park. It’s a quiet vantage point over a city that has quietly become one of the nerve centers for cloud infrastructure and AI. When I talk about “AI systems architecture,” I’m not talking about a single clever prompt — I’m talking about the scaffolding: multi-agent workflows, semantic memory, and protocols that make behavior predictable.
This post is a walkthrough of how I think about AI systems architecture from that vantage point in Seattle — as a builder, a dad, a U12 girls soccer coach, and someone who resets every day with hot pilates and yoga at TruFusion Ballard. The work and the life are intertwined: discipline, structure, and iteration show up in both.
Why “Systems Architecture,” Not Just Prompts
The easiest thing to build with AI is a single model call with a big prompt. The hardest thing to build is a system that:
- Has clear responsibilities for each component
- Preserves memory across steps and tasks
- Can be debugged and reasoned about
- Survives change in models, tools, and data
My work is aimed squarely at the second category. When I say “AI systems architecture,” I mean the design of the protocols, memory, and orchestration that sit around models and make them behave like part of a living system.
Core Ingredients: Memory, Orchestration, Protocols
In practice, AI systems architecture for me comes down to three pillars:
- Semantic memory – a structured way to store and reuse state.
- Agentic orchestration – something outside the models that routes work and enforces rules.
- Protocols – clear, repeatable formats for how agents and tools communicate.
On this site, you’ll see those ideas show up as things like Cube Protocol and the orchestration work referenced on the Projects and Code pages. Under the hood, I’m trying to build an ecosystem where agents don’t just talk — they exchange well-formed packets that can be inspected and replayed.
Multi-Agent Workflows: The Controller Outside the Model
Real multi-agent systems are not just a single model pretending to be different roles. They have:
- A supervising controller (the orchestrator)
- Capability-scoped agents with clear responsibilities
- A shared memory substrate
- Execution rules — timeouts, retries, and permissions
My controller layer is the part that lives outside any one model. It decides:
- Which agent should handle this step?
- What memory should they see?
- What format should their output follow?
- What happens if they fail or return an invalid packet?
That logic is grounded in the same thinking I apply when I’m coaching a U12 girls team: every player has a role, the field has structure, and we run patterns — not random chaos — even if each game is different.
Semantic Memory from Seattle: Why Context Has to Persist
Living near Discovery Park, it’s impossible not to think in terms of context and landscape. The model’s context window is a narrow viewpoint; the system’s memory is the full map. If you want agents to do meaningful work, they need access to:
- What has already happened
- What decisions were made and why
- Which data was used and how it was structured
That’s why I work on semantic memory systems like Cube Protocol: to create reversible, structured memory packets that can be stored, inspected, and reused. It’s not enough for a model to “remember” in some fuzzy sense — the system needs a durable, testable representation of what happened.
Protocol-First Design
Protocols are the quiet backbone of any robust system. For AI, that means:
- Standardized packet formats for requests and responses
- Clear schemas for memory entries
- Consistent interfaces between agents and tools
The work I do in my GitHub repositories is often about exploring new protocol shapes: how can we encode this state so it’s cheap to store, easy to reconstruct, and self-explanatory to another agent or system?
Life Rhythms That Keep Systems Work Sane
The way I approach systems is heavily influenced by my routines in Seattle. Coaching soccer forces me to think in terms of roles, structure, and long-term development rather than short-term wins. Living across from Discovery Park means regular walks and resets that keep my thinking clear.
Daily training at TruFusion Ballard — especially hot pilates and yoga — reinforces discipline and pacing. You can’t rush adaptation, whether it’s a system, a team, or your own body. That mindset shows up in how I design AI architectures: small changes, consistent habits, and clear feedback loops over time.
How This All Shows Up in Code
If you want to see this philosophy in practice, the best place to look is my code:
Those repositories are not just demos — they’re how I test system ideas: new memory formats, orchestration patterns, and ways to make AI behavior more structured, reversible, and trustworthy.
Closing: AI Systems Architecture From Magnolia, Seattle
When you search for “Phil Hills Seattle”, what you’re really looking for is a picture of who I am now: an AI Systems Architect in Magnolia, building protocol-driven AI systems, raising a family across from Discovery Park, coaching youth soccer, and training most days at TruFusion Ballard.
This mix of work, family, community, and routine is what shapes my approach to AI systems architecture. The code and protocols are one expression of that — the rest is lived here in Seattle.