The Context Gardener

The software engineering landscape has been rapidly changing. Over the past three years, we have rapidly transitioned from a simple inference / chatbot setup showing some promise with writing functions to steering multi-agent semi-autonomous teams of task-specific agents.

My take is that modern software engineering is less about writing code and more about actively curating the context which undergirds the AI implementation team.

How We Got Here

To understand the context garden, we first need to explore some of the new patterns and configurations available to us. I don't want to get too detailed but (ironically) some extra context is necessary for folks who haven't been building with multi-agent teams.

Chat Bots

At this point, many have had experiences talking to an LLM chatbot on the web. The LLM you chat with has a limited context window for housing that conversation. You've certainly experienced context degradation* which is when the quality of the LLM outputs drop as a result of either the context filling or too many disconnected concepts which can confuse the transformer.

Agents

While these chatbots are still around, we've wrapped inference in tooling which enables LLMs to take actions in an environment (write code) or react/retrieve information from it's environment (external process trigger, reading documentation)

These agents have the same limitations as a chatbot--Their context can degrade if it fills or contains too many topics.

Multi-Agent & Workflows

Once we were able to build a single coding agent that could interact with the filesystem, reading & writing code, it was only a matter of time before multi-agent teams started to exist.

Below is my current swiss-army-knife team that I'm using day-to-day.

❯ ll ~/.claude/agents
total 160
-rw-------@ 1 john  staff   8.5K Dec 30 18:46 architect-planner.md
-rw-r--r--@ 1 john  staff   4.6K Nov 27 14:42 code-reviewer.md
-rw-r--r--@ 1 john  staff   7.9K Nov 27 14:42 devops-expert.md
-rw-r--r--@ 1 john  staff   6.8K Nov 27 14:42 junior-engineer.md
-rw-r--r--@ 1 john  staff   8.4K Jan 18 10:55 project-planner.md
-rw-------@ 1 john  staff   6.8K Dec 31 12:06 senior-nextjs-engineer.md
-rw-r--r--@ 1 john  staff   8.6K Nov 27 14:42 senior-python-engineer.md
-rw-------@ 1 john  staff    11K Nov 27 14:42 ui-design-expert.md

The primary Claude Code agent I interface with in the CLI almost never writes any code. Instead, it acts as an orchestrator delegating tasks to the subagents on my team.

This helps with:

1. Longer coding sessions (I don't need to deal with the primary agent compacting all the time, it's context is just distributing tasks to the team)
2. Less context degredation--each agent's context is only populated with information related to their domain and task.
3. Parallelization. I have dispatch multiple agents to work on different aspects of a problem simultaneously.

This is all fantastic--but can quickly result in a messy codebase with no standards enforced, if all agents are operating independently with vague tasks. This is a recipe for LLM generated spaghetti code.

The Garden

Now that you have an idea of why the agent team exists, it's time to better understand their interplay on the filesystem and how this garden grows. At the time of writing this article, the orchestrator model is great for delegating tasks to subagents, but inter-subagent communication is lacking. Thus, I instruct my agent teams to use {PROJECT_ROOT}/llm_memory to each offload context, save work, ask each other questions, etc.

Below is a simplified view, showing the agents using the directory llm_memory for their working memory and reading from a specs folder that contains reference material.

This results in a very dynamic workspace. As I'm steering my team towards a programming objective, the orchestrator is dispatching tasks to agents--writing relevant context to llm_memory folder, citing reference material we've ironed out ahead of time in the specs directory. While each agent works, they're offloading context & questions to each other in llm_memory as they work.

Parallel to the inner-workings of my implemntation team, the code base rapidly expands and changes.

Pruning Context / Weeding

Over time this results in long term context bloat. Instead of an individual agent's context being filled, our shared memory folder becomes cluttered. Cluttered with old implementation successes, deprecated patterns long forgotten, etc.

While I tend to my software garden, I'm constantly on the look-out for reference material becoming inaccurate, insufficient, or bloated filesystem working memory. So, I find myself developing processes and agents to deal with managing working/reference context.

Over time, this really makes a software project feel like a living garden. There are pieces of it we want to foster and develop, and there are parts that (if left unchecked) can become overgrown and rob the flowers of water and sunlight.

Watering with Specs & Tooling

I've hinted before at having a specs directory for my team to reference. This is where I'll maintain concrete references for api contracts, models, maybe varying levels of detail into different logical mechanisms of the application. It is ultimately project material for agents to reference again and again.

I will often structure my specs as backlink markdown files. This is a form of progressive disclosure which is particularly LLM / Context friendly when leveraged effectively.

We have established before, that context rot / degradation can occur when the LLM's context passes a certain threshold. Backlinked markdown enables LLMs to progressively find the information they require, instead of filling their context with every document.

SKILLS via ClaudeCode and other CLI agent tools use this same pattern. I consider hydrating the LLMs with accurate reference material. Similarly, tooling (light playwright mcp or context7) can also provide LLM's with the ability to find information needed to accomplish a task correctly.

Managing specs & tooling isn't static. While it might seem that reference material and tooling might be a one-and-done step, in my experiences it's part of this new living software organism we're tasked with managing. I will often watch how my teams implement, and consider if information needs to be supplied to them differently. Do I need to point to specific tools or docs in subagent prompts? Do I need to break apart the existing material into smaller files, or expand upon certain examples? Is there an opportunity to repackage reference material into a skill zip & port to other humans for usage in their AI teams?

Growing & Maintaining Software Gardens

I'm not a gardener, and I'm certain I've missed or fumbled a few metaphors here; But, hopefully I've been able to somewhat convey this strange new world we find ourselves in. When I'm barely writing implemented code, but instead managing this ecosystem of semi-independent agents, shared-memory, and shifting reference material--while watching a code base appear from specs--It feels like I'm managing a garden.

As the patterns solidify, and we begin to scale these agent teams at some point we may become software farmers.

Happy Coding! gardening?