When everyone in the community is chasing multi-agent systems, it’s hard to say no to one in your own design.

I feel that pull too. So I ask myself five questions based on what I’ve read, and the third one matters most.

𝟭. 𝗖𝗮𝗻 𝘆𝗼𝘂 𝘄𝗿𝗶𝘁𝗲 𝘁𝗵𝗲 𝘀𝘁𝗲𝗽𝘀 𝗱𝗼𝘄𝗻? If they rarely change, a workflow is cheaper and far easier to debug.

𝟮. 𝗗𝗼𝗲𝘀 𝘁𝗵𝗲 𝗽𝗮𝘁𝗵 𝘃𝗮𝗿𝘆 𝗳𝗿𝗼𝗺 𝗼𝗻𝗲 𝗶𝗻𝗽𝘂𝘁 𝘁𝗼 𝗮𝗻𝗼𝘁𝗵𝗲𝗿 𝗶𝗻 𝘄𝗮𝘆𝘀 𝘆𝗼𝘂 𝗰𝗮𝗻’𝘁 𝗽𝗿𝗲𝗱𝗶𝗰𝘁? Debugging an unusual production failure often does. Extracting fields from invoices usually doesn’t.

𝟯. 𝗖𝗮𝗻 𝘆𝗼𝘂 𝗰𝗵𝗲𝗰𝗸 𝘁𝗵𝗲 𝗿𝗲𝘀𝘂𝗹𝘁? Every other answer depends on this one. If you can’t score the output, you can’t tell whether an agent outperforms a workflow or whether it’s improving. Without a way to evaluate results, choosing an agent is a guess.

𝟰. 𝗖𝗮𝗻 𝘆𝗼𝘂 𝗮𝗳𝗳𝗼𝗿𝗱 𝗮 𝗺𝗶𝘀𝘁𝗮𝗸𝗲 𝘁𝗵𝗮𝘁 𝘁𝗮𝗸𝗲𝘀 𝘀𝗲𝘃𝗲𝗿𝗮𝗹 𝘀𝘁𝗲𝗽𝘀 𝘁𝗼 𝘀𝗵𝗼𝘄 𝘂𝗽? A long-running process that fails can produce a wrong answer in the same confident tone as a correct one. If one such mistake is costly, the bar for choosing an agent goes way up.

𝟱. 𝗜𝘀 𝘁𝗵𝗲 𝘃𝗮𝗹𝘂𝗲 𝘄𝗼𝗿𝘁𝗵 𝘁𝗵𝗲 𝗰𝗼𝘀𝘁? You can’t answer that without knowing the success rate, which brings you back to question three.

Quote:
“Many use cases positioned as agentic today don’t require agentic implementations.”
Anushree Verma, Senior Director Analyst, Gartner, June 2025

Every AI assistant that answers from your documents has to connect the dots somewhere. You only get to choose when: before anyone asks, or while they wait.

That one choice is the clearest way I know to explain GraphRAG and Agentic GraphRAG.

Plain RAG does the least of both. It indexes your documents so similar passages are easy to find, runs one search per question, and lets the model connect whatever comes back. Cheap, and fine until the answer needs two facts that live in different places.

Pay now. GraphRAG reads your documents ahead of time and draws a map: this person leads that project, this part comes from that supplier. The connections are ready before anyone asks. The bill comes back every time your documents change.

Pay later, and keep paying. An agent skips the map. It searches, reads what came back, notices what’s missing, and searches again, while the user waits.

Agentic GraphRAG does both. Two bills, and sometimes worth it.

It comes down to two numbers: how often your documents change, and how often a question needs facts from more than one place. The first is your map bill. The second is what the map buys you.

Pay now or pay later: which one did your team choose, and was it on purpose?

Quote:
There are no solutions; there are only trade-offs.
Thomas Sowell

Claude Code, Cursor, GitHub Copilot, Windsurf, ChatGPT, Gemini — I call them my assistants.
Lately, I’m not so sure who’s assisting whom.

Agentic tools keep handing me decisions in the same shape:
– Option 1 (Recommended)
– Option 2
– Other

When I know the domain, I actually choose. When I half-know it, I read the alternatives and make a decision. And when I don’t know enough to judge? I click Recommended and call it trust.

It reminded me of Delegation Poker from Jürgen Appelo’s Management 3.0, which describes seven levels of delegation between a manager and a team:
Tell → Sell → Consult → Agree → Advise → Inquire → Delegate

Tell – I make the decision and announce it. No discussion expected.
Sell – I make the decision, but I explain my reasoning and try to get you on board.
Consult – I ask for your input first, then I make the decision.
Agree – We discuss it and decide together, by consensus.
Advise – You make the decision, but I give you my recommendation first.
Inquire – You make the decision, then explain it to me afterward.
Delegate – You decide, full stop. I don’t need the details.

Map that onto an agent session, and the level can shift by the minute. And some afternoons, I’m just the Clicker:
– Read the summary.
– Hit Approve.
– Move on.

Here’s the uncomfortable part: Clicking Approve on a plan you can’t evaluate is Delegate wearing an Consult costume. An approval step only counts if you have enough context to reject it.

So now I try to choose the delegation level per decision, before the session starts, based on two things: Blast radius and reversibility.

Formatting? Fully delegated. Anything touching data, architecture, or high-level design? I stay involved.

Maybe, after all… I’m not sure who’s assisting whom. I started calling AI my assistant. Now I’m wondering if I should start calling myself the assistant to my assistants. 😂
Okay, let me ask my boss.

Foreword: Thorngate’s postulate of commensurate complexity

The postulate of commensurate complexity is a description of a phenomenon in social science theorizing. Karl E. Weick claims that research in social psychology can always only possess two of the three meta-theoretical characteristics: ‘Generality’, ‘Accuracy’, and ‘Simplicity’. Therefore, one of these three characteristics must always be subordinated to the other two. Simply put, a model can only possess two of the three characteristics of being general, accurate, and simple, and never all three simultaneously.

This postulate is named after the Canadian social psychologist Warren Thorngate from the University of Alberta. In describing the problem, he states: “In order to increase the generality and accuracy of theories, their complexity must inevitably increase.”

Karl Weick used the image of a clock below to illustrate this concept. On this clock, at 12, 4, and 8 o’clock, the three terms Generality, Accuracy, and Simplicity are written. Now, pay attention to the concepts of 2, 6, and 10 o’clock:

– 2 o’clock: Research is universally applicable and highly detailed, but it becomes complex and loses its simplicity.

– 6 o’clock: Research is useful for a specific context, but its results are not generally applicable to other contexts and lack generalizability.

– 10 o’clock: Research is universally applicable and easily understood, but it lacks sufficient detail and high accuracy.

Karl Weick claims that you must make a tradeoff when choosing these three characteristics, because only two of them are achievable at any given time.

Discussion: What time is it in your model’s world?

The interesting point is that Thorngate’s model can be applied to software. And what’s even more interesting is that when we face a problem and want to provide a solution for it, we map out certain aspects of the solution (read: the model) in our minds.

Let’s solve a simple example together. We want to design the database for a small banking system that handles deposits and withdrawals. Do you consider two separate tables for deposits and withdrawals, or a single table named “transactions” that includes both? Now, if you look at your own solution through the lens of simplicity-generality-accuracy, what time are you positioned at?

Now is the time to review some of your previous solutions and see what time it is in the world of your solutions.

Source:

The idea for this post comes from the book Mastering DDD by Annegret Junker.

In 1995, Watts Humphrey handed every developer a personal process.

It failed.

His Personal Software Process (PSP) let a single developer run a defined, measured, continuously improving process. It worked, but the bookkeeping killed it. Time logs, defect logs, forms after every task. Almost nobody could sustain it. Humphrey moved on to team processes, and for thirty years the smallest unit of process design has been the team.

I think that just changed.

Look at what an AI coding assistant actually gives you:

→ Skills: reusable SDLC activities such as analysis, design, testing, review
→ Subagents: roles with responsibilities
→ Hooks: quality gates that run every single time
→ Memory files: your standards, written down

Put these together and you have a full process, with you as its designer.

To be clear, this is not the “army of agents” story. The agents were never the point. The point is that the machine now absorbs the overhead that killed PSP: the constant logging, measuring, and enforcing. Humphrey was right. He was just thirty years early.

I call it the Process of One. It’s what I’m building now.

I’m designing my own process: the activities, the roles, the quality gates, the retrospectives. Everything I once designed for teams, I now design for a team of one. And this time, the machine carries the bookkeeping that defeated Humphrey.

The first rule of AI engineering applies at this level too: if you don’t measure it, you’re guessing. So I hold my own process to the same standard I hold the AI systems I build, and I keep asking: does it actually work?

You are a team of one now, with a process of one. How would you design yours?


Comment:
I’ve also started a catalog of these patterns: 19 so far, researched and organized together with the very assistant they describe. Each one written the same way: the situation, the problem, the solution, the source. Link on GitHub.



Quote:
Nothing that exists in the world is outside of you.
Seek within yourself whatever you want,
for that you are!
Rumi

If you use AI for coding every day, you may have noticed something strange: Your AI coding assistant gets dumber the longer you talk to it.

Most developers feel it but can’t name it: you start a chat, it’s brilliant. An hour later — same model, same task — it’s forgetting your instructions and repeating bugs it already fixed. You blame yourself. Don’t.

Matt Pocock calls it the smart zone and the dumb zone. A model is sharp early in a session, then quality slips well before the chat feels “full.” And here’s the surprising part: those huge new context windows everyone is talking about? They don’t give you more smart zone. They just give you a bigger dumb zone.

(Technically: a model’s effective context length is much shorter than its advertised window. As the thread grows, attention spreads thinner across more tokens, mid-context detail gets underweighted — “lost in the middle” — and the model keeps conditioning on its own earlier mistakes still sitting in the history.)

So the fix isn’t a better prompt. It’s a shorter memory. One task. One conversation. Then start fresh.

For larger work, move the memory outside the conversation: define the destination in a a shared specification, break the journey into small independent tasks, and give each task a clean context. The goal isn’t to give the AI everything it could possibly know. It’s to give it exactly what it needs for the task in front of it.

Your assistant was never getting tired. It was getting full.

Highly recommend Matt Pocock’s “Full Walkthrough: Workflow for AI Coding.” I learned a lot from this workshop.

Source:
Matt Pocock’s “Full Walkthrough: Workflow for AI Coding” (AI Engineer). The smart zone / dumb zone section is worth the watch if you use an AI assistant daily: Link

One practical tip from it: keep a token counter visible in your setup, and clear the chat when a task is done rather than stacking the next one on top. A fresh session beats a smart prompt.

Excerpt:
Every breath, the world is made new — and we, unaware of our renewal, endure.
Rumi, Masnavi

Almost everything I’ve ever built has been retired, replaced, or shut down. Except one. It has no users to please, no metrics, no roadmap, no deadline. And next month, it turns twenty.
It’s a weblog.

I started it on a Friday in the summer of 2006 — جمعه سیزدهم مرداد 1385 — in Persian, on one of the old blogging platforms, with no plan and no audience. I called it Somamos, after the highest peak in Gilan, in the green north of Iran. My family’s village, Bibalan, sits on the plain below, with Somamos rising on its horizon. The name was how I kept home in sight.

There was never a topic. There was only a rule I didn’t know I was following: if I loved it, it went in. A line of classical poetry. A book, a film. A thought about language. A knot in some code I’d finally worked loose. An idea in AI I was still turning over. A memory I refused to lose.

A public notebook, written for my friends.

It outlasted jobs. It outlasted cities. It crossed the ocean with me to Canada and didn’t miss a beat. Twenty years of software came and went around it — platforms died, formats changed — and the notebook just kept filling.

It lives at bibalan.com now, and recently it learned a second language: I’ve started making it bilingual, Persian and English side by side. I’ll be sharing some of these pieces here on LinkedIn too — so they reach not just the friends I wrote for in 2006, but the ones I haven’t met yet.

Twenty years ago I shared what I loved with people I knew.
Now I’m sharing it with you.