Levi Garner Levi Garner

Operating model

How I run engineering
with a team of twenty agents.

Most teams operate AI as a feature. Drop a chatbot in the corner. Add a generation step to a workflow. Call it AI-native.

I operate AI as the org. Twenty agents across four layers. Each scoped, each with memory, each with judgment inside its boundary. The same domain-driven thinking I used to design event-sourced enterprise systems, applied to the organization itself.

AI is smart but blind. The architecture is what gives it sight.

Layer 01

Coding agents

Claude, Codex, and Cursor running inside structured harnesses. PRD-driven. Vertical slice execution. Memory-backed. Each agent has a scoped repository understanding and acts inside feature boundaries, not across them.

  • Feature-first vertical slice architecture
  • PRD + DESIGN.md before any code
  • Memory persisted across sessions, not just turns
  • Branch-isolated worktrees per agent task

Layer 02

Personal cognition

I dogfood the same intelligence pattern InteliG ships at organizational scale, scoped locally to myself. Persistent memory across notes, meetings, and conversation. The local version proves the pattern works before I install it inside an org.

  • Persistent memory across every interaction
  • Notes, calendar, and inbox unified as a single reasoning surface
  • Same architecture pattern as InteliG Cognis
  • Local dogfooding feeds back into product decisions

Layer 03

Product agents (Cognis)

Inside InteliG, Cognis reasons across the execution graph: code, strategy, meetings, finance, contributors, initiatives, decisions. Not retrieval. Causal understanding accumulated over time.

  • Agent loop with tool catalog (ReAct pattern)
  • Three memory layers exposed as tools
  • Evidence accumulation, not summarization
  • Cross-pillar reasoning across the graph

Layer 04

Ops agents

Outreach, content, scheduling, lead pipelines, social, research. Each with scoped responsibility and bounded memory. None are workflows with LLMs attached. Each has judgment, context, and a defined role in the org.

  • Role-scoped memory boundaries
  • Defined handoff protocols
  • Output reviewed, never blindly shipped
  • Continuous role refinement

Operating principles

The rules that make this work.

  1. 01

    Architecture before tooling. DDD, CQRS, Event Sourcing apply to agent teams too.

  2. 02

    Memory is the unlock. Without it, every agent is a stranger.

  3. 03

    Agents have scope. The harness enforces the boundary.

  4. 04

    Judgment lives in the operator. Agents execute under it.

  5. 05

    Replace, do not patch. When the model is wrong, reset the primitives.

Why this matters for the buyer

When I install this inside a portfolio company, the math changes.

Headcount is the largest line item in software cost. Most engineering spend is coordination overhead, not creation. Reduce the coordination tax and the team that ships a roadmap gets smaller. Reduce the visibility tax and the CTO stops running a status meeting.

I do not sell agent installation. I sell the architectural conditions that make agents reliable. Memory boundaries. Domain models. Reasoning layers. Without those, agents fail at scale and the team reverts to Jira theater.

This is the operating model I bring to value-creation engagements. It is not theoretical. I run it on myself every day.