Thinking About Agent Systems Through the Construction of Mathematics

It took me a long time to move from execution to thinking, and longer still to understand where thinking should begin.

I built a house that could collapse at any moment

I had already spent some time working with AI Agents. I progressed from the ChatGPT chat box to carefully writing system prompts, building workflows with Dify and n8n, and eventually entering an AI IDE for Vibe Coding. Every layer had pitfalls and lessons; at each I thought I had reached a new level.

For a time, I built what I considered a fairly complete Agent system in Trae IDE: roles for strategic thinking, content creation and data analysis, and dozens of Skill documents defining atomic capabilities. From the outside it had architecture, responsibilities and standards, much like a company.

But when I tried to use it for a specific task, it collapsed. Not technically: the logic collapsed.

Agents passed responsibility back and forth, instructions weakened as they traveled, and information was lost at each handoff. I spent 80% of my time debugging the system and only 20% doing actual work.

A pseudo-system: I was not building a system; I was playing a business simulation. I was managing a one-person studio with the logic of a large company.

I thought adding a layer of rules would be enough

After reflecting, I did something that seemed right: add a Harness.

I borrowed the term: in software engineering it refers to a test framework; in Agent development it refers to a system of behavioral constraints that defines conceptual boundaries, prescribes processes and tells AI what to do and not do.

I thought carefully about what Skills and Agents are and how they relate. I wrote execution procedures, data-trust levels, a routing matrix and completion criteria. The system became more orderly, and AI behavior more predictable. Yet something still felt wrong.

The rules grew finer, documents multiplied and standards became more complete—but that completeness was fragile. One day, looking at the rules folder, I asked: where did these rules come from?

Most came from mistakes. When AI did something wrong, I wrote a rule to prevent repetition. When it confused two tasks, I wrote a rule to distinguish them.

Essentially, this was a collection of patches inferred from practice, not a system of rules derived from principles. Patches address known errors; principles address all situations, including those not yet encountered.

My mistake: using execution to solve a problem at the level of thinking.

I reversed the question: how was the edifice of mathematics built?

My background is financial engineering, so mathematics was familiar, but I had never thought to use its construction logic for Agent systems. Then I asked: has humanity built an internally consistent body of knowledge whose conclusions can be traced to foundations and that has endured two thousand years of scrutiny?

Yes: mathematics.

Its construction logic was the opposite of my intuition. I acted, encountered trouble and added rules. Mathematics starts by defining foundations, then derives each step rigorously upward.

It was not a smooth journey. Mathematical history has had several crises, each digging deeper into the foundation:

Each advance began by acknowledging an error and rebuilding foundations.

The counterintuitive lesson: progress began with admitting mistakes and rebuilding, not adding rules. When Russell found his paradox, he did not patch Frege's system; he said the foundation was wrong and had to be rebuilt. That was not failure, but honesty.

Another idea impressed me even more. Before axioms, mathematics has something more basic: undefined primitives. In ZFC set theory, “set,” “element” and “belongs to” (∈) are not defined.

Mathematicians did not forget. These terms cannot be defined in the usual way because every definition would need them; they must precede definitions. Mathematicians instead characterize their behavior through axioms: specifying what properties ∈ should satisfy without saying what ∈ is.

Defining and characterizing are different. That distinction later clarified a long-standing question for me, but that is another article.

Three knives for examining my system

I examined my system against three mathematical standards: independence, consistency and completeness.

Independence: axioms must not be derivable from each other

Think of load-bearing columns. If one rests on another, it is not an independent support; removing it changes nothing.

Looking at my principles, “simplicity”—prefer the smallest working solution, and prefer three similar lines of code to premature abstraction—could be derived directly from Occam's razor.

Occam's razor: a fourteenth-century friar named Occam proposed choosing the simpler of two explanations that account for the same phenomenon. Applied to solutions, it naturally produces simplicity.

“Simplicity” was therefore a corollary, not an independent axiom; I moved it down the list. In my system Occam's razor means that before adding a rule, role or file, I ask: what would the system lack without it?

Consistency: rules must not contradict one another

I found a three-way conflict. Suppose I ask AI to do something requiring an irreversible action:

• Reversibility: prefer actions that can be undone; if an action cannot be undone, pause for confirmation.
• Ownership: complete an assigned task; don't push complexity back to the user.
• Occam: minimize actions, including the overhead of confirmation.

All three apply, pointing in different directions. Which wins? The original documentation gave no answer.

The three-way conflict and the solution of a total priority order.

Each time this occurred, AI had to use its own judgment—the very thing my rule system was supposed to avoid.

The solution was an explicit total priority order. If reversibility fails, the cost cannot be recovered; if truthfulness fails, contamination spreads; if ownership fails, the efficiency loss can be remedied. Ordered from highest to lowest, conflicts have a mechanically executable answer.

Completeness: cover the cases the system claims to cover

My routing matrix said what to do but not why. It was a lookup table, not derived decision logic. More fundamentally, the system had no type layer.

Consider grammar: before sentences, a language needs basic definitions such as noun, verb and adjective. Without them, grammatical rules have no objects to operate on.

My system had never formally defined Skill, Agent, Task or Deliverable. Its rules operated on untyped concepts—like a language with verbs but no nouns.

While establishing types, I faced a subtle question: what needs defining? My answer was: define only things for which AI would otherwise behave incorrectly.

“Skills must be stateless” needs a definition: without it AI might write a Skill that retains conversation history and behaves unpredictably when reused. “What is a README?” does not: AI already knows it from training, and its understanding matches our needs. The boundary is whether we must impose a behavioral contract.

Results of the three checks

Test	Problem	Repair
Independence	Simplicity follows directly from Occam's razor; it is not an independent axiom	Move it to a corollary
Consistency	Reversibility, ownership and Occam conflict without an arbiter	Add a total priority order
Completeness	Routing says what but not why; core objects lack types	Create types only for objects needing behavioral contracts

Rebuilding: foundations before floors

I rebuilt in layers, each preceding the one above: Axioms → Types → Theorems → Operations → Applications. Each derives from the layer below; a lower layer does not need to know the one above it.

Each layer is derived from the one below.

Every rule must be traceable to its layer and source axiom.

Discovery one: the theorem layer. Initially, operating procedures sat directly above axioms. Calling procedures “execution standards derived from axioms” is not wrong, but it mixes proven conclusions with their operationalization.

Mathematics distinguishes them: a theorem is an important proven statement, a lemma is a smaller conclusion helping prove a theorem, and a corollary follows directly from a theorem. I inserted a theorem layer between axioms and procedures for proven conclusions. Procedures became cleaner, concerned only with how to act; reasons live in the theorem layer, and each procedure points to its theorem.

Discovery two: system language. While building the theorem layer, I used mathematical notation for formal definitions. Symbols can be more precise than prose and remove ambiguity at boundaries, but are unfriendly in articles. My solution: use symbols as a working language in internal rules and prose in output such as articles and reports. The test is whether a symbol removes ambiguity prose cannot; use it if yes, otherwise use prose.

Some key definitions:

• Skill: a stateless input/output function: the same input produces the same output, without hidden state across calls.
• Agent: a stateful, multi-stage execution process that may call Skills but may not nest another Agent in the same context, to prevent state contamination.
• Workflow: a directed graph of tasks with dependency constraints; task topology, not an executor.
• Memory: persistent state across sessions, strictly separate from Context, the temporary state within a session. Memory writes are not easily undone, so the reversibility axiom applies.
• Deliverable: has provenance requirements: every number or conclusion in it must be traceable to a source file.

The incompleteness boundary: finally, I added a section explicitly listing cases the system does not cover. Gödel proved that any sufficiently strong system has true statements it cannot prove. This is not a defect but honesty. My system too has cases it cannot handle; list them and, when they occur, state the boundary rather than pretending otherwise.

The rebuilt system had roots. One question remained: where does the brand layer go? The five layers have no place for it. Looking for one revealed a deeper question about mathematics, AI and branding—not just an Agent-system problem.

Tool limits: an unavoidable compromise

The rebuilding took place in Claude Code, an AI-native command-line tool that embeds AI deeply in development. It can read and write files, execute commands and call external services, with the whole project directory in view. Unlike ordinary chat AI, it does more than answer: it actually operates in the working environment.

But it has a physical constraint: configuration files must be under .claude/ for automatic loading. My axiom and type files are the system's foundation and source of all rules, yet in the filesystem they appear under a tool directory, like software configuration.

The file structure says “tool parameters”; in reality they are the organization's brain.

I could not fully resolve the contradiction. The tool's constraint is real, and philosophical neatness should not break the system. I did two things:

1. In the system's most visible document, I stated that this placement is a tool requirement, not a declaration of hierarchy. Physical location does not mean the contents are logically subordinate to the tool.
2. Inside the tool directory, I organized files strictly by logical layer—axioms, types, theorems and procedures—compensating for what the physical hierarchy cannot express.

I also created an alignment reference describing Claude Code's execution model. If the tool changes, it tells a new tool the system's behavioral baseline and what it must align with—a small hedge against dependency.

I used Claude Code to build a marketing AI work system, but neither the tool nor the field is the point. The point is the shift in thinking.

It took me a long time to move from execution to thinking: to see that the problem was neither code nor an insufficient prompt, but a lack of system coherence. The larger leap was understanding where thinking should begin.

Not by inferring rules from experience, creating patches. First find truly independent, mutually consistent first principles at the bottom; then derive each layer upward from the one beneath it.

This is a construction logic accumulated over more than two millennia. Euclid derived geometry from five postulates not because he knew only five things, but because he knew which five were foundations from which everything else could grow.

Applied to Agents, the result is a rooted system: every rule knows why it exists, each component knows its layer, and conflicts have mechanically executable paths to resolution.

Chaos does not disappear, but it has a way out.