I arrived at this setup gradually over the past year. Want the whole story? No? Fair enough. Let's get to how I actually work, with examples, pictures and stories from real life.
1. The right GUI is half the battle
May the console faithful rain curses upon me.
I don't enjoy working in a terminal. I'm not afraid of it; I know how to open one. But with several projects, several conversations in each, and constant switching, I want a proper window with understandable tabs. Ideally, I can find the right one without remembering which identical terminal contains Claude fixing Android and which contains Codex explaining why we shouldn't touch anything.
It's a peculiar saving: we get AI to write code to free our hands and heads, then occupy them with window management, copying answers and finding chats. Excellent work, everyone.
Before the instructions, then, here's the interface I use: Paseo. It brings different agents together. Claude and Codex remain Claude and Codex, with their models and usage limits, while I get one place to open projects and work with them. The underlying agent tools need to be installed and configured; Paseo manages them, rather than supplying a magical programmer of its own.
Naturally, I found it by the shortest possible route: first I decided to build something like it myself. We even started, before I remembered our favourite question: “Fancy looking for an existing solution?” I tried options including Goose and OpenClaw, and eventually found Paseo. One bicycle narrowly escaped receiving a rocket engine.
I wanted projects, chats and providers together, plus usable access from my phone. I've tried the native Claude and Codex apps and still do occasionally, but something tends to get in my way: awkward switching, a dropped remote session, an elusive action. Perhaps I'm simply used to Paseo now. Fine. I'm choosing a tool for me.
My Mango workspace has Claude, Codex and a tab called “Secretary”. The first two handle the main work; the secretary is a small agent on a simpler model. “Write down this thought.” “Find where we discussed that.” “Look this up.” It saves interrupting an agent wrestling with a complicated problem. A three-line note doesn't need a meeting of the Academy of Sciences.
The secretary has no lifelong allegiance to a provider. Whoever has more allowance left gets the job. My choice between Claude and Codex is often less philosophical than internet debates suggest: one's limit has run out, the other's hasn't. To make switching possible without retelling the project's entire life, we need the system we're getting to.
Even with both available, I sometimes want one to review the other's proposal. With the appropriate tools available, Paseo agents can contact other agents, including ones from another provider. I discovered this almost accidentally: Codex got stuck, I told it to pass the task to Claude, and there was Claude in the subagent list. I'd expected to play courier again. The parcel had delivered itself. We stopped, investigated and documented the possibility.
That doesn't mean I can leave them to agree on a perfect product. It does sometimes remove text delivery from my job description. Personally, I'm still unconvinced that putting them together to chatter in one shared conversation is a good idea.
The phone matters too. I use Paseo on my laptop, home Mac Mini and phone, so leaving home doesn't end the work. The agent, files and commands stay on the computer; the phone provides access. Naturally, the computer must remain awake and reachable. No magic, just things like caffeinate -dimsu.
Paseo is free and open source. That doesn't eliminate the providers' charges for using models, but I didn't need another subscription just for a convenient window.
I could paint a picture of building apps on the beach, coconut in one hand, phone in the other. In reality, I do about ninety per cent of the work at a computer. The phone lets me keep things moving: read an answer, clarify a task, save a thought or tell an agent it's wandering off again. I return to the computer for test installations and store releases. Agents are explicitly forbidden to install things on my test phones or deploy to production without my instruction. How reliably that works is another story.
When choosing your interface, look at ordinary things you repeat constantly. Can you find the project, see who's doing what, read long replies and continue from another device if needed? A small irritation, repeated all day, becomes a large one.
Right. Comfortable interface, agents in their seats. Now they need to know where they're working and where to put what they learn. Otherwise, each soon develops its own notebook, rules and version of events.
Bring out the holy napalm. Time for global instructions and agent memory.
2. Burning personal memory with holy napalm
Tabs weren't enough. I once discovered a remarkably industrious Codex with almost a parallel set of project documentation in its personal directory: changelog, handovers to itself, an index and even server-state records. The latter accumulated entries like “No server changes were made in this session.”
Nor in this session. Nor this one. No server activity; ever more documentation. A pedant. I love it.
There were also preferences of mine, useful observations and conclusions I hadn't necessarily agreed with. We had to sort these into their projects. I didn't want project knowledge living in one agent's notebook, which the other had no obligation to read.
Imagine two employees with shared instructions. One also keeps a private notebook recording what they think you meant. Yesterday you changed the procedure and updated the shared instructions. Their notebook still says the old thing. Today they follow the notebook. You ask what the hell happened; they confidently point to the page. There it is, written down. Just the wrong thing in the wrong place.
This happened quite literally with my agents. Claude once looked for a release build in the wrong directory, couldn't find it and explained that I'd built the wrong thing. The correct path was already in project memory. It trusted an old entry elsewhere. Checked everything, explained everything, blamed me. Beautiful.
My principle is simple: project knowledge belongs in the project, so Claude, Codex and I consult the same place. An agent can help write a rule; I don't need its privately maintained alternative edition.
A little terminology helps. I used to call everything “memory”. There are instruction files, notes saved for future sessions, and the current conversation's context: messages, file excerpts, command output. Related things, not one enormous pot. A history directory's disk size doesn't tell you how much text the model currently receives. Cleaning saved notes doesn't erase an ongoing conversation.
By “burning memory”, I mean that unauthorised second archive of project knowledge. First recover anything useful, verify it and put it where it belongs. Deleting the entire settings directory, authentication and all, is a different form of entertainment.
You can start without changing anything. Ask the agent where its instructions come from and what it stores outside the project:
Read-only. Show the user-level and project instruction files active in this session. Find saved notes about this project outside its directory. Give each location's path and purpose, and briefly describe the notes. Identify duplicates and contradictions with project documentation. Do not output authentication settings or secrets.
Then read the answer. Insist on actual files and entries, not an elegant lecture about artificial memory. It can produce that too, sometimes instead of answering.
At one point I had Claude watch what Codex wrote in its own directory, then swapped them. A tiny internal audit department whose auditors periodically needed auditing. That helped me understand where extra records came from and which rules needed changing.
Don't move the entire pile into the project and declare it tidy. If the agent wrote “Alex always wants this”, ask Alex. Perhaps I requested a temporary workaround once and the machine promoted it to constitutional law. Transfer confirmed decisions, mark obsolete information, remove duplicates after checking. Moving a rubbish bin between rooms isn't quite cleaning.
Next, establish a short entry point. Codex commonly uses ~/.codex/AGENTS.md for user instructions; Claude Code uses ~/.claude/CLAUDE.md. The tilde means your home directory. Codex's directory can be overridden, and AGENTS.override.md takes precedence over the ordinary global AGENTS.md, so establish what your installation actually reads.
What I mainly want in global instructions is a pointer:
Do not save project history, decisions or notes in the agent's personal memory. When working in a project, first read its AGENTS.md and follow its entry procedure. Save project knowledge in that project's documents. Report missing instructions rather than pretending they exist. Do not independently add to global instructions.
That's a shortened example of the message I want the agent to encounter at session startup. These user-controlled instructions aren't the same thing as the provider's underlying system prompt.
Our architecture, the release directory and yesterday's design decision belong in the relevant project. They don't need to accompany the agent into every unrelated conversation.
I want both agents reading common project rules. Claude Code has its own CLAUDE.md entry point, which can import the shared AGENTS.md using @AGENTS.md. That avoids maintaining two diverging copies. We'll organise the project documents next time.
Another distinction: writing “don't keep memory” in an instruction isn't the same as disabling an automatic memory feature. Claude Code, for example, lets you turn off auto memory through /memory. If your interface or agent has another note-saving mechanism, investigate that separately. One sentence in Markdown isn't a universal off switch for everything called memory.
Now the unpleasant question: do the agents always behave after this?
Ha. You've met them by now.
In my experience, Claude more readily went to read project instructions, then forgot to record results until reminded. Codex diligently maintained documents but occasionally grew another personal notebook. After changing the setup, I inspect a fresh session: did it find the rules, record the result in the right place, start another little archive elsewhere? “Understood, won't happen again” opens a conversation; it doesn't close the task.
I want a simple outcome: when I switch agents, the project's agreements remain available and consistent. Then I can choose who to work with without remembering which one carried off the last correct explanation.
Which raises the obvious question. We've hung up a sign saying “read the project documents”. The agent has obediently arrived.
What exactly is there to read?
Next time, we'll prepare the project directory and see how to make that preparation repeatable.
Sources and further reading: