AI Systems & Agents
How to choose an AI agent setup — path, harness, and models
Part 1 was the thinking. This is what you do with the answers.
Three decisions. That is the whole part.
- Which path are you actually on?
- Which harness is home.
- Which model tier does which job.
The worksheet at the end is the form. This article is how to fill it in without buying four more subscriptions because a launch video made you feel behind.
Bring your Part 1 answers. If you skipped Part 1 and came here for the toys, go back. You will pick a stack that does not match your week. I have done that. It is a very expensive personality trait.
Decision 1: which path
Most people start in chat. Ask. Answer. Better prompt. “I could automate my whole job.” Then the copy-paste loop starts. Prompt. Copy. Paste. Missing file. Paste more. Context fills. It forgets. New chat. Re-explain.
That is not automation. That is a fast typewriter with a memory problem. An expensive one.
A better model makes a better typewriter. It doesn’t turn you into a workforce. I spent a long time learning that the expensive way. Custom GPTs. Claude Projects. n8n. Notion databases. The models got better. I was still the integration layer, the memory, the scheduler and the QA. Very busy. Not a system.
Codex, Claude Code, Cursor and Grok are not chat boxes. They are harnesses. Tools, memory, subagents, scheduling, MCP, parallel work. The old line “a single tool cannot do that” is dead. If you are still saying it, you are behind. I was saying it too. The tools moved on.
So the question is not “does my tool have features.” It is whether you have stopped using one harness and started assembling a second one out of parts, in your head.
You are at that ceiling when:
- the same model is wearing five hats and none of them fit
- you are bouncing work between Codex, Claude, Cursor and Grok and keeping the real memory in your skull
- your “board” is a list you ignore
- “check your work” is the only guardrail
- you are still the person who glues it together
That is not a stack. That is you, building a Blue Peter project with sticky-back plastic.
Adopt or assemble.
If Part 1 said one process, and that process fits in one harness, stay there. Ship the work. Come back when you hit the ceiling. Do not build a factory around a job Codex will finish in an afternoon.
If Part 1 said you are already routing models by hand, running a separate board, writing your own checks, and wishing Tuesday’s conversation still existed, you are already assembling. Pick a home. Do not keep building it out of tabs.
Map it from Part 1. Not from ambition.
- One process. Light time. Light budget. Stay inside one harness. Codex, Claude Code, Cursor, Grok, DeepSeek, take your pick. Pick one and stop shopping.
- Assistant. A few areas. Moderate time and budget. You need a home that remembers you, talks where you already work, and can run a couple of jobs without you watching. Still small.
- Team. Several workstreams. Real hours. Real money. Now you need lanes, a ledger, scheduled work, and someone other than you checking the output. This is where Hermes sits for me. Codex and Claude still do real work. My agents live in Hermes.
Grey area? Start simpler. You can add a lane later. You cannot easily unpick a team you built because you thought you would “need it eventually.”
Write the path on the worksheet. One line. “Your starting path is ___.”
Decision 2: which harness is home
A harness is the operating system. The model is the engine.
A Ferrari engine in a shopping trolley still handles like a shopping trolley. I have bought a lot of different engines in the last 2 years.
Every serious harness now does some mix of this:
- more than one agent, with different jobs
- memory that survives the session
- tools: terminal, browser, files, mail, GitHub, APIs
- scheduling
- a ledger, not a shopping list
- guardrails that are actual gates, not “please be careful”
You don’t need all of that on day one. Match it to the path.
One process. You already have a harness. Terminal, files, enough memory for the job. Do not add a second OS because the feature list was longer.
Assistant. One or two agents. Memory that lasts. Terminal and browser. A simple schedule. A channel you actually open. You don’t need a Kanban religion yet. You don’t need independent QA yet. If a vendor is selling those as the reason to start, they are selling a team you don’t have.
Team. Three or more agents with lanes. Short-term, long-term and shared memory. Broader tools. Cron and watchdogs. A board that assigns, promotes and flags stale work. Evidence gates. Someone who can fail a job without asking the agent who wrote it. That is a home. Hermes is the one I use. It is not the only one. Desktop app, Telegram, Buzz. One ledger. The brand matters less than whether those jobs are actually covered.
Required versus optional. If a missing required feature is hidden behind a shiny optional one, walk away.
Memory is the bit people underestimate, then drown in. Memory is like a filing cabinet. Nobody wants to do the filing. Everyone wants the files.
- Short-term is this session. It dies when the window fills. Everyone has this. It is not a strategy.
- Long-term is preferences, corrections, how you like things written. It needs storing, fetching, updating and pruning. Otherwise it becomes folklore.
- Collective is the board, the docs, the history more than one agent can see. Hardest. Stale shared memory is worse than no memory. You will trust it because it is written down.
Budget time for memory. It is maintenance, not a checkbox. “Just use a vector database” is how you get a very confident pile of odds and ends.
Rabbit holes, so you can walk past them:
- building your own harness because none of them “quite fit”
- treating chat-plus-upload as a harness
- buying the team package for one process
Match the home to the path. Not to the longest landing page.
Decision 3: which model tier does which job
Everyone talks about cost per token. That is the wrong number.
The right number is cost per finished job. A cheap model that needs five retries, plus your evening, can cost more than one clean, expensive run. A frontier model doing donkey work is just you setting fire to money with extra steps.
I have done both. One week I burned through millions of tokens because a frontier model was doing work a cheap model should have had. The reverse also hurts. Cheap models fail slower. You sit there “saving money” while it politely wastes your night.
Before every job, answer three questions:
- How hard is this? Heavy reasoning, or just get it done.
- What if it is wrong? Annoying, or a mess you cannot unwind.
- How often? Once, or all day every day.
If you cannot answer those three, the model is not the problem. The job is.
Then pick a tier. Not a brand. Brands change names for sport.
- Frontier reasoning. Architecture. Strategy. Nasty debugging. High cost of failure.
- Fast capable. The workhorse. Drafts, code, research synthesis. Most of the week lives here.
- Cheap fast. Monitoring, classification, simple extraction, watchdogs. The jobs that should not need a PhD.
- Specialist. Design, vision, a domain model that actually earns its keep.
Right model for this job, this failure cost, this budget. Never “we only use X.” Model loyalty is how you pay frontier prices for inbox sorting.
How to evaluate, on your work, not a leaderboard:
- Pick three to five real tasks you actually do. Not demo tasks. Yours.
- Run the same input through two or three candidates.
- Score each one: correct or not, usable / needs a rewrite / start over, time, tokens.
- Do it again next month. Models drift. Providers change things and do not send an update card.
If you are on the assistant or team path, and being wrong is expensive, check across providers. Here is the catch with harnesses: most of them are single-provider. Sonnet does the work and Opus does the checking. That is not independent review. That is the same family marking its own homework. Same-family checks are real and useful, and they still share blind spots. Different providers fail differently. That is the point. Don’t do this on every spelling pass. You will go mad, and the bill will help.
Rabbit holes:
- cheapest model, always
- frontier model, always
- marrying a vendor
- shopping benchmarks like they are the work
Look at the bill to learn. Not only to panic. I start with a cheaper model, run it once, and then get another model to check the work. If it is substandard, I move to a higher model and repeat.
Fill the worksheet, then go and build something
Download the Part 2 decision worksheet →
You should leave with four things written down:
- Your path. One process, assistant, or team.
- What the home harness must do for that path. Required versus optional.
- First routing rules, in tiers. Not brand names.
- Three to five real tasks you will use to test models this month.
Then do the first build. Not the whole vision. One job.
- Install the harness you picked. If you picked a single tool, you already have it.
- Point it at the one process from Part 1.
- Run it once. Watch it. Fix what breaks.
- Run it again tomorrow.
That is the moment the paper stops and the system starts. Everything from Part 3 onwards is about making that first job survive contact with a real week.
Part 3 is lanes and the board. How work moves so you stop being the sticky-back plastic. Skip it if you honestly picked one process and you are staying inside one harness. You can come back when one job becomes several.
If you cannot write those four lines, you are not ready to install anything else. That is not a stall. That is you saving next Saturday.
Following along?
I publish these as I go — every experiment, including the expensive dead ends. Get the next one by email, or connect on LinkedIn where these start as posts.