DEV Community: John Lee

What AI Engineer Job Ads Actually Screen For

John Lee — Wed, 09 Sep 2026 07:29:22 +0000

Decide to become an AI engineer and the first thing you meet is a framework list. Learn LangChain? People say LangGraph is rising. What about CrewAI, AutoGen? Picking wrong feels like it will cost you a year.

The posting data settles that anxiety first. An agent-specialist job board tallied 1,135 of its own listings from March–May 2026 (the site doesn't name its operator, so read it as a snapshot). More than half of those ads name no framework at all. The ads that do name them average 2.31 each: LangChain in 392, LangGraph 256, LlamaIndex 150, CrewAI 106, AutoGen 74; and even LangChain, the market default, appears alone in only one of its eight listings. This is not a pick-one game.

The salary data points the same way, harder. Postings that name frameworks have medians of $185–190K, roughly $20K below the agent segment's overall median of $213K. Naming frameworks doesn't buy you a premium. For scale: the posted-salary median across 43,480 US AI-engineering ads is $176,000 (Axial Search). The agent segment sits a bit above that, though the two tallies differ in window and method, so don't read the gap as precise.

Of the five functions AI jobs sort into, this installment covers Application.

The sentences that repeat in real postings

Strip away the framework lists and read what senior postings ask for, and different words keep coming back. Two engineering ads and one PM ad that states the same demands from the other side. Condensed here; originals at the links.

"Design evaluation harnesses and quality scoring — we use Langfuse, rubrics to measure safety, effectiveness, and personalization." (Future, Applied AI Engineer, $215,000–250,000)
"Improve our observability and instrumentation to profile agent behavior… design and implement infrastructure for low-latency agent execution." (Harvey, Senior and Staff Software Engineer, Agents, $193,400–340,000)
A role partnering with engineering and AI leadership across LLM orchestration, latency, caching, reliability, evaluation, observability, and cost; the phrase "cost per successful outcome" comes from here. (HighLevel, Principal PM, Conversation AI)

What the three postings share isn't a framework name; it's evals and operating numbers. And an eval isn't anything exotic: it's automated grading of whether your system answered well, against a set of reference answers you wrote: a golden dataset.

You can put down the fine-tuning worry

The fear that this job requires training models keeps a lot of builders out. In a survey of 1,340 practitioners (LangChain's own survey, late 2025), 57% do not fine-tune at all. The working baseline is a base model plus prompting plus retrieval (RAG), tightened by evals. In the same survey, 57.3% already run agents in production and 89% have some form of observability. Learning evaluation and operations gets you closer to the ads than going back to ML math does.

Tool names barely appear in the ads

Eval tools are only starting to register in job ads. In UK posting counts (ITJobsWatch, 2 September 2026), just two names show up at all: LangSmith (38 postings over six months) and Langfuse (31); Braintrust has no page. The salary columns aren't readable yet either; last year's samples were two or three postings each. That thinness is the signal: what companies screen for isn't a tool name but whether you can design evaluations and read operating numbers.

One protocol is the exception. MCP (Model Context Protocol) shows up in 17–24% of postings for every one of the five frameworks, the only thing in that data that cuts across all of them. Its security problems are growing just as fast, so "I can use MCP" has to mean "I can use it safely."

One fast-growing title deserves a caution: Forward Deployed Engineer, embedded with customers and accountable through production, grew 729% in a year on US Indeed's index. But the same title spans two pay tiers: an FDE at a frontier lab and an FDE at an ordinary enterprise are different jobs. Don't judge by the title alone.

The actual size of the Australian market

If you're reading from Australia, set expectations from local numbers. On SEEK, "ai engineer" returns 1,177 listings, "langchain" 30, and "llm" 101 (2 Sep 2026; keyword matches, so treat ratios loosely). LLM-specific roles are still few. The named hiring is real: Commonwealth Bank, including its subsidiary Bankwest, is hiring GenAI and agentic engineers, and recruiter listings run to AUD $230–340k. Rough bands: $130–165k mid, $165–200k senior, $200–230k+ principal (aggregated from recruiter guides such as Big Wave Digital, not official statistics).

So what do you build?

Not a framework mastered; one small thing finished. Build a retrieval-backed Q&A over some documents and write fifty reference answers yourself. Automate the grading, measure latency and cost per request, and keep the records. Those are the words the postings above keep repeating.

What this project gives you is hands-on experience with evaluation and instrumentation. It does not substitute for the production-scale experience the senior ads also want. But juniors who arrive having done it are rare. You'll touch a couple of frameworks building it. You don't need to finish learning them first.

Next up: Enablement, the role that helps employees actually use AI well.

Why YouTube Only Teaches You n8n

John Lee — Thu, 03 Sep 2026 15:56:44 +0000

Open YouTube to learn automation and you get n8n, Make, Zapier. The enterprise-market tools from the last piece (Boomi, Workato, UiPath) are almost nowhere. The job ads clearly want them; the content layer barely mentions them.

The easy answer is views: beginners are the audience, so beginner tools win. That's half of it; the other half is where the money comes from. Follow who pays the teacher.

The first money: affiliate commissions

n8n runs an affiliate program for creators: 30% of referred cloud-subscription revenue, for twelve months. Every viewer who signs up through a creator's link becomes recurring income for that creator, and Make runs a similar program. Zapier has no affiliate program open to ordinary creators; it holds the same shelf space through search dominance instead.

Enterprise vendors don't pay creators this kind of commission. There is no per-signup commission open to individuals. Workato and UiPath do run partner revenue programs, but the money arrives after a partner agreement and a closed enterprise deal. A video can't collect on that, so a YouTuber teaching Workato has effectively nobody to collect from.

Which means a creator's menu was set before the first video went up.

The second money: the community business

The monetization point in automation education now sits below the videos, on Skool, a community platform. The two biggest automation communities there, AI Automation Agency Hub (330,000+ members) and AI Automation Society (440,000+), are both free.

The free tier brings people in, and what's sold behind it differs by operator. AI Automation Society sells a $129-a-month membership to its 440,000 free members; the AAA Hub side sells an accelerator priced above $5,000 to its 330,000 (pricing disclosed only on a sales call; that figure comes from student accounts). Where the published numbers allow an estimate, at AI Automation Society, the paid share sits under 1%: 447,000 free vs 3,700 paid is 0.8%. Strictly a paid-to-free count taken on the same day, not a conversion rate.

Skool adds a competition on top. Skool Games ranks community owners each quarter by the new subscription revenue they add in 90 days, and the leaderboard counts at most $100 a month per subscription. The contest is built for low-priced volume, and the curriculum that sells at volume is a low-barrier tool. The answer, again, is n8n. High-priced accelerators aren't subscriptions, so the leaderboard doesn't count them at all.

The other side is nearly free, and invisible

Enterprise education is much bigger and barely shows up on YouTube. UiPath Academy reported 1.6 million learners (UiPath, 2023). Salesforce Trailhead issued 2.6 million+ AI and data badges in the fifteen months from June 2023, about 40% of them going to Salesforce's own employees. Workato's courses and exams cost nothing.

Workato aside, what's free is the training, not the credential. UiPath's official exams run $150–300, and Salesforce's free first attempt at its AI certifications ended at the close of 2025. The credential track itself is churning under the AI transition: Microsoft retired its Power Automate certification this year and replaced it with an agent certification.

Creators teaching the enterprise tools do exist. There are channels devoted to Power Automate, and the Salesforce world supports a paid-course market of its own. But since no vendor pays per signup, those creators have to earn outside the vendors, at a much smaller scale. Which leaves learners looking at an inverted world: the education that costs money is the most visible, and the education that's nearly free is the hardest to find.

This is not a scam story

Some things deserve saying in the other direction. The big accelerator's review score is solid: 4.7 on Trustpilot across 548 reviews, though the account actively invites customers to review, so read it with that in mind. A different community backs itself with a full-refund 90-day guarantee tied to landing your first client (Maker School, $184 a month). Freelance-market guides put n8n rates at $40–100 an hour, $125–250 senior (agency tallies, not marketplace statistics). Real people earn real money in this market.

The problem isn't fraud. It's distortion: several hundred thousand people are being trained toward the smallest part of the market companies actually pay for, and the direction was set by the teachers' revenue structure rather than the learners' needs.

How to use the content layer anyway

Learning n8n is fine in itself — the last piece showed real jobs on it and real enterprises adopting it. Three things to keep.

Check whether a channel teaches only the tool its affiliate links point at. A curriculum with one tool as every answer is a funnel, not a curriculum.
Before paying for a course, sweep the free tier: vendor academy training costs nothing, enterprise ads recognise vendor certifications, and a $150–300 exam is cheaper than most paid courses.
Spend what's left, money and hours, on records. Whoever's hiring reads a workflow with an error rate and throughput attached before any certificate. That was the last piece's closing table.

Next up is Application: what AI engineer job ads actually screen for, once you set the framework names aside.

There Are Two AI Automation Job Markets

John Lee — Wed, 02 Sep 2026 07:53:05 +0000

Automation is the door most people pick when they start an AI career. You watch n8n videos on YouTube, join a community, take a course, and start preparing for a job or an agency. The sheer number of people learning it tells you something: the two biggest free automation communities alone hold 770,000+ members combined (as of August 2026, overlapping signups included).

Then you open the job ads and the names look wrong. "8+ years hands-on Boomi." Workato, Celigo. Tools you have never seen on YouTube, paying more than the ones you have. Somewhere around here you start wondering whether you learned the wrong thing.

You didn't. There are two markets, and YouTube only shows you one of them.

The AI Operator Map split AI careers into five functions. This installment covers Automation, one of them.

The two markets, side by side

	Startup & agency market	Enterprise market
Who hires	Startups, agencies	Large companies, regulated industries
The tools	n8n, Make, Zapier	Boomi, Workato, Power Automate, UiPath
Typical titles	AI Automation Specialist, GTM Engineer	Integration Engineer, RPA Developer
Where you learn	YouTube, communities, paid courses	Vendor academies, certifications (often free)

The startup side's speed shows up in job ads. In an analysis of 1,000 GTM and RevOps postings (Bloomberry), those roles grew 205% in Jan–Sep 2025 over the same months a year earlier, with a median salary of $127,500. The tools the ads name: Zapier in 39% of postings, n8n in 28%, and Workato doesn't appear on the published tool list at all.

The enterprise side barely exists on YouTube. But the hiring is steady, and learning it costs less, not more. Workato's courses and exams are free, and UiPath's academy training is free too (the official certification exams start at $150). And don't let the "8+ years" ads scare you off: those are the top of this market, not its entrance. The entrance is already paved: free academy, certification to pass screening, junior integration and RPA developer postings.

Two titles in that table deserve a definition. A GTM engineer automates go-to-market work, meaning sales and marketing operations. An RPA (Robotic Process Automation) developer builds software robots that take over repetitive on-screen work people used to do. And the enterprise column itself has two grains: Boomi and Workato are integration platforms (iPaaS) that connect systems to systems, while UiPath's core is RPA.

So why did the market split in two? To see it, you have to take the word "automation" apart.

"Automation" is not one thing

Job ads and interviews talk past each other because one word is covering four different distinctions. Split them and the ads start making sense.

1. Who is in whose loop?

Sometimes the human owns the process and the automation helps. A support ticket comes in, a workflow classifies it and drafts a reply, but a person reads it and hits send. Sometimes the automation owns the process and the human is a checkpoint: invoices flow through untouched, and only the ones over a threshold land on someone's desk.

The first is AI-in-the-loop (the AI joins your loop). The second is human-in-the-loop (you join the automation's loop). A lot of material online uses the two interchangeably; there is a research paper whose whole point is untangling them, and its test is a usable one: who owns the process? Get this distinction right in an interview and the conversation moves up a level.

2. Who decides the path?

Put a trigger on an n8n flow and drop an LLM node in the middle, and the path is yours. The AI summarizes or classifies in its assigned slot; the next step is always known. The industry calls this a workflow. An agent is different: you give it a goal, and the AI decides what to do next and which tools to use. What you own are the goal and the guardrails.

Anthropic, the company behind Claude, gives blunt guidance here: use the simplest pattern that passes your evaluations, and save agents for problems where you cannot script the path in advance. An "agentic" keyword in a job ad does not always mean the job is building agents. If you can explain why something needed to be an agent, you stand out.

3. Where does the human watch from?

Some roles approve every action (in the loop). Some watch a running system and step in when something looks off (on the loop). Some hand the whole thing over (out of the loop). This isn't new either: since the 2010s the RPA industry has used a similar split between attended robots (assisting at someone's desk) and unattended ones (running headless). Tools keep changing; the axis stays. When an enterprise ad asks for "human oversight" and "exception handling," this is the axis it's talking about.

4. Autonomy comes in levels.

Researchers have proposed an L1–L5 scale. At L1 the human makes every decision and the AI only executes. At L3 the AI leads and the human gives direction and feedback. At L5 the human keeps an emergency stop and little else. Gartner expects task-specific agents inside 40% of enterprise applications by the end of 2026, up from under 5% in 2025. Agents inside everyday enterprise apps are about to be common.

The two markets, re-read through the four axes

What YouTube and the courses teach is mostly automation that stays near a person: it runs while you watch, and you fix it when it breaks. Enterprises use plenty of near-a-person automation too — attended robots next to call-centre agents, for one. But the point where the two markets' prices split is the other kind: automation that runs all night with nobody watching, brings only the exceptions to a human, and passes a security review.

The price bands differ from the start. n8n cloud starts at €20 a month; Workato's average contract sits in the mid-$60,000s a year (Vendr, 2026). Feature lists don't explain that. What does: large companies, especially in regulated industries, review a tool's security before adopting it and demand a contract that says who is liable when something goes wrong. Zapier holds a SOC 2 certification, but SOC 2 attests that security controls were audited; it doesn't substitute for specific regulations. Handling data covered by HIPAA, the US health-privacy law, requires a liability agreement (a BAA) that Zapier declines to sign, so organisations that need one can't pass it through review. What an enterprise product sells includes those contracts and that review-readiness, not just features.

The tool you're learning is not a dead end

Three things are happening at once.

There are already good jobs on startup-market tools alone. That's the GTM engineer above: hired by startups, working in Zapier and n8n.
Enterprises have started using startup-market tools. Delivery Hero (53,000 employees) used n8n Enterprise to cut account-unlock time from 35 to 20 minutes on average, reclaiming 200 employee-hours a month (n8n's published case study); BMW is wiring n8n into an internal platform (independent scan by Bloomberry).
The enterprise tools themselves are being rebuilt around agents. UiPath has re-positioned the whole company on "agentic automation," and Workato is opening its automations to be called by agents.

Whichever direction you take, though, the last thing you have to show is the same.

What companies actually buy

Not "I can build it" — "it ran, and here is the record." The further the automation gets from human hands, the heavier the record they ask for.

Where the human sits	The record they ask for
Human owns it, automation assists	Before-and-after: what got faster, by how much
Automation runs, human supervises	Error rate, throughput, run logs, intervention log
Human hands-off	Full monitoring setup and audit trail

In portfolio terms: swap the workflow screenshots for an error-rate graph. Certificates don't appear anywhere in this table. Paid courses aren't the problem; it's that the record still has to be built after the course ends.

If you're learning n8n right now, nobody is telling you to stop. Know who owns the process in the thing you're building, know where the human watches from, and start attaching error rates and throughput. If I were screening, I'd look at that one record before ten certificates.

Why does YouTube only teach the kind that runs next to a person? Next up, we follow the money.

The AI Operator Map: AI Jobs Sort on a Different Axis

John Lee — Wed, 02 Sep 2026 07:52:45 +0000

A while back a message landed in my LinkedIn inbox. A recruiter at an AI-specialist firm here in Australia: they were placing AI talent with clients across the country, my profile had stood out, would I be keen for a chat. I said yes, but honestly not for the role. I wanted to know what demand for AI people actually looks like in this market, straight from the people who sit behind the job ads.

Which is how that call turned into two interviews running at once. They were measuring me against their ladder, three tiers from hands-on operator to executive, AUD $70k to $250k and up. I was trying to read the market off them: what problems are companies actually hiring people to solve?

But my question wasn't anywhere on their ladder. Hire two people at the same tier and you can get two completely different jobs: one automating internal workflows, one building products on LLMs. Different experience required, different evidence to show. The ladder had no row for that distinction. The call ended and I still didn't have my answer.

So I went and checked myself: job postings, salary guides, national statistics. Every number in this piece carries its source and its definition; the stage is the Australian market, and global surveys are marked as such. You'll see why by the end.

The names the market uses collapse into five

Strip away the titles, group by "what problem does this person solve", and you get five functions. Not an industry standard — a grouping I built from the postings and the surveys.

Function	The problem it solves	Titles the market actually uses
Automation	Rebuild workflows that logic-based tools never could	AI Automation Specialist, Integration Engineer, GTM Engineer
Application	Build products where the model does the data work CRUD used to do	AI Engineer, LLM Engineer, GenAI Engineer
Enablement	Move an existing workforce onto AI	AI Enablement Lead, AI Adoption Specialist, AI Academy Lead
Product & Architecture	Design the path from AI spend to revenue	AI Product Manager, AI Solutions Architect
Governance	Make AI cleared to ship	AI Governance Specialist, Model & AI Risk Manager

Five rows and the map would be done, except the moment you search by title, the table starts coming apart.

Titles churn. Functions persist.

It isn't just titles — the credentials around them churn too. This year's evidence alone:

Microsoft retired the Power Automate RPA developer certification (PL-500) in June 2026 and put a new agent certification (AB-100) in its place. The credential name swapped; the automation function underneath didn't move.
"Chief AI Revenue Officer" circulates in content everywhere. I could not find a single person who actually holds the title.
Forward Deployed Engineer postings grew 729% in a year on Indeed's data, and the role sits across two functions, Application and Architecture, so it fits no single cell.
One Melbourne government posting for an AI Enablement Lead bundles the AI roadmap, responsible-AI governance, and the organisational learning program into one hire.
In IAPP's survey, 68% of privacy professionals have taken on AI governance as a second hat.

So the unit is the function, not the title. In the postings, small organisations bundle several functions into one person, and the bigger the company, the more each function gets its own team. Adoption itself tracks size too: per the Australian Bureau of Statistics' 2024–25 business survey, 35% of large businesses use AI, 22% of mid-sized, and 11% of small and micro businesses.

Tools track company size as well. n8n, the center of gravity of YouTube automation content, didn't make the grid of the 2026 Gartner Magic Quadrant for iPaaS at all (a mention in the text, no more), while the leaders are Boomi, Workato, SAP, Salesforce, and Microsoft. Half the companies running self-hosted n8n have 2 to 10 employees (Bloomberry's certificate-log scan of self-hosted instances; cloud customers aren't captured). n8n is inside big companies too; what splits isn't presence but the procurement and production-approval layer. Why the tools YouTube teaches and the tools companies actually buy differ this much deserves its own piece, so just one line here: enterprise vendors don't pay YouTubers affiliate commissions. SMB tools do. n8n pays 30% of referred cloud-subscription revenue for twelve months.

"Can't I just learn whatever and go?"

I wish. The failure data says it's not that simple.

Quoted failure rates for enterprise AI run anywhere from 30% to 95%, and they measure different things in different units, so they can't be lined up on one scale. Pull out any single number and you almost certainly distort it.

What was measured	Number	Source
Projects predicted to be abandoned after PoC	30%+	Gartner, 2024
Companies that abandoned most AI initiatives	42%	S&P Global, 1,000+ respondents, 2025
PoCs scrapped before production	46% avg	same survey
Companies failing to achieve and scale value	74%	BCG, 1,000 CxOs, 2024
Companies with no tangible enterprise-level EBIT impact	80%+	McKinsey, 2024 survey
PoCs that never reached wide deployment	88%	IDC with Lenovo, 2025
Organisations with no attested P&L impact within 6 months (custom tools)	95%	MIT NANDA, preliminary report, 2025

If you've seen "95% of AI projects fail" somewhere, it comes from the bottom row: a preliminary report, not a peer-reviewed study, built on 52 interviews plus 153 conference surveys and a review of 300-odd public initiatives. The real limits are its six-month window and interview-attested outcomes, and the same report found that roughly 83% of generic chatbot pilots succeed. This is why every number in this series carries its source and its definition.

Where the surveys do overlap, despite their different bars, is an observation: in McKinsey's, BCG's, and MIT's data alike, the successful minority defined the outcome before building and redesigned the workflow instead of laying a tool on top. Correlation, not proven cause, but the direction is consistent. My reading: this market is short on people who know what to measure.

And AI skills already carry a price. Australian job ads asking for AI skills grew little for four years, then doubled from 20,000 to 41,000 in a single year, and those ads carry an average 62% wage premium (PwC AI Jobs Barometer, Australia 2026; by industry it ranges 8–59%). Demand is growing, but which size of organisation you join changes the tools you'll meet and the evidence you'll be asked to show.

Each function has its own evidence

That's why the last column of this map is evidence, not tools.

Function	What counts as evidence
Automation	Workflows live in production; error rate, throughput, monitoring
Application	An eval harness; latency and cost per request; a golden dataset
Enablement	Measured behaviour change; before-and-after on a real workflow
Product & Architecture	Revenue or cost movement tied to something that shipped
Governance	Framework fluency (NIST AI RMF, ISO 42001); a policy that survived a real review

If some terms in the table are unfamiliar, that's fine. What an eval harness is, how you measure behaviour change: each function's installment will unpack them one at a time.

Evidence isn't something you can batch up later. Build with measurement attached from step one and it accumulates alongside the work itself. Which function, measuring what, and how — those are the cells this series fills in.

If you're weighing up your AI career right now, pick the problem you want to solve, not the title. The experience you build solving it becomes the foundation for everything after.

Next up: Automation.

Obsidian Git Sync on iPhone Works Better Than You'd Expect

John Lee — Mon, 24 Aug 2026 08:44:22 +0000

In the previous guide I put my Obsidian vault on GitHub. I promised to write up the mobile setup separately, and this is that write-up.

The short version: on an iPhone, the Git plugin alone handles pull, edits, commits, and pushes. I set mine up back in February, forgot about it, and the phone has been picking up the latest vault every day since. It keeps working after you stop thinking about it.

Your phone runs a different git

On desktop, the Git plugin calls whatever git you have installed. An iPhone has no git to call, so on mobile the plugin switches to isomorphic-git, a JavaScript reimplementation. The author warns in the README that mobile is unstable, and SSH doesn't work there. Authentication is HTTPS with a token, and that's the only option.

The warnings sound like a reason to give up. My vault is 25MB with 319 markdown files, and at that size I've never felt the problem.

The setup

You don't need iSH, Working Copy, or any other companion app. The plugin does everything.

Create a token. On GitHub, generate a fine-grained personal access token. Repository access: just your vault repo. Permissions: Contents, read and write. Give it a name that says what it's for. The reason comes below.
Install Obsidian and the Git plugin on the phone. Create a new vault (turn off "Store in iCloud"), then install and enable Git from the community plugins.
Clone. Open the command palette (on mobile, the default gesture is swiping down) and run "Git: Clone an existing remote repo". It asks more questions than you'd expect. In order:
- Enter remote URL: your repo address (https://github.com/user/repo.git)
- Directory: pick Vault Root.
- Does your remote repo contain a .obsidian directory?: if you commit your settings the way the previous guide does, answer YES. A scary confirmation follows ("DELETE ALL YOUR LOCAL CONFIG AND PLUGINS"). It means the empty vault's config gets replaced by the one in your repo, so go ahead. Your plugins and settings come back from the repo once the clone finishes.
- Depth of clone: leave it empty for a full clone.
- username / password: username is your GitHub account, and the password field takes the token. GitHub rejects account passwords for git, so a token is the only thing that works here.

The clone throws plenty of warning notices along the way. Mine finished fine through all of them. When it's done, Obsidian asks for a restart.

After the restart, finish the settings. Fill in the commit author name and email in the plugin settings; commits from the phone fail without them. "Pull updates on startup" should already be on if your repo carries the settings, so just check it. With that on, the app opens on the latest state every time.

I deleted the token and sync stopped

While writing this I was cleaning up my GitHub token list and saw the vault token marked "Never used". It had been pulling every day for months. I figured it was a leftover and deleted it, and the phone's sync broke on the spot.

A fresh token pasted in brought everything back. And that new token, minutes after a successful push, still shows "Never used". GitHub's Last used label doesn't count git authentication. Trust it while cleaning tokens and you'll cut a working sync, like I did. That's why the token gets a name that says what it's for.

On the phone, I mostly read

My pattern is simple. I write on the Mac and read on the phone. The app opens, the pull runs, and the latest vault is in my hand wherever I am. When a thought lands while I'm out I type a line, and that gets committed and pushed too. Since the writing happens on one side, the conflicts from the previous guide almost never show up on the phone.

That guide said to lower your expectations for mobile. Correction: at this vault size, there was nothing to lower.

Codex PR Review: Automatic Reviews, Triggers, Review Rules

John Lee — Mon, 24 Aug 2026 08:43:54 +0000

Codex's GitHub PR review works better than I expected. Before opening a PR I already review the code several ways, in Claude and in Codex both. I've had the main agent review it, attached a different model as a subagent reviewer, run it in two stages. Code that survives all of that still gets caught by Codex, always one or two things.

This guide covers turning it on. What happens after that is a bigger story, and I pick it up at the end.

Turning it on

Setup itself is three steps.

Set up Codex cloud for the repo. That means installing the GitHub app and granting repo access, and you need push or admin permission to change repo settings.
In Codex settings, toggle Code review on for the repo.
To have every PR reviewed without asking, also turn on Automatic reviews. Leave it off and Codex only shows up when you call it.

Automatic review also means the review lands the moment you open the PR. If you'd rather not collect comments on a draft, leave it off and call Codex when the branch is ready.

You call it from a PR comment.

@codex review: review this PR
@codex security review: look at it from a security angle
@codex review for issues in the database migration: narrow where it looks
@codex fix the P1 issue: have Codex apply the fix itself

To pin review standards into the repo, add a ## Code Review Rules section to AGENTS.md and break it into ### items. Repo-wide rules go in the root file; rules that only apply to one service go in the AGENTS.md closest to that code.

One more thing worth knowing: Codex only posts P0 and P1 findings to GitHub. Small stuff never shows up, so anything that does usually carries weight. That's exactly what makes it hard. Every comment looks correct.

Setup takes five minutes. The rest is the hard part.

What happens once it's on

Codex judges strictly from the code, and both the side filing comments and the side fixing them are built to keep going until they're done. If nobody steps in, the rounds multiply on their own. One security-feature PR passed through 209 review conversations before it merged.

Living through that cycle left me with four response principles: read comments from how the product behaves, weigh them by user impact, understand how the fix relates to the existing code before touching anything, and if it isn't a merge blocker, file an issue or ignore it. Where those principles came from and why each one holds is in 209 AI Code Reviews: Accurate Is Not Necessary. If this guide got your reviews turned on, that post is what to read next.

Managing ChatGPT Memory: Review, Edit, Delete

John Lee — Mon, 24 Aug 2026 08:43:47 +0000

ChatGPT remembers you whether or not you asked it to. If its answers start matching your tone one day, or it explains something on the assumption you do a job you never mentioned, that's memory.

It isn't only ChatGPT. Claude has memory, and so do most of the coding tools shipping now. The model consults it to give you the answer you're more likely to want. Use it without knowing about it and you have no way to explain why an answer came out the way it did.

There used to be a step where you said "remember this" and one line got stored. Not anymore. ChatGPT keeps track of whatever it judges worth keeping from your chats. So this guide is about managing it rather than switching it on.

Two screens are in circulation right now

The memory settings screen started changing in June 2026. The new one has a single memory control and a memory summary. The summary is a written account, organized by category, of what ChatGPT thinks it knows about you, rather than a list of stored items. The old screen has two toggles ("Reference saved memories" and "Reference chat history") and shows the saved items as a list.

The new screen is arriving by plan and region, so your account may still show the old one. What follows describes the new screen, with notes where the old one differs.

Reading and correcting the memory summary

Settings → Personalization → Memory. The path is the same on web and in the app. Many accounts have memory on already, so opening it to see what's in there comes before switching anything on.

Open the memory summary and you get what ChatGPT has written down about you. Most people are surprised the first time they look. You can correct it two ways: type the correction, or highlight a sentence in the summary and delete it. To clear the lot, use "Delete and turn off memory" from the three-dot menu on that page. It does what it says, wiping the summary and turning memory off with it.

On the old screen you get two toggles instead. Saved memories are managed as a list of items; chat history reference has no list at all. If you cleared every saved item and ChatGPT still seems to know you, the second one is on.

One trap: deleting a conversation does not delete the memories that came out of it. Clearing your chat list and clearing your memory are separate jobs, so something you thought you cleaned up can keep feeding into answers.

Seeing what went into an answer

A personalized answer comes with a way to see which information fed it, and you can edit that information from there. Grabbing one answer that came out wrong and deleting the cause is faster than reading the whole summary.

Keeping memory inside one project

Projects have their own memory setting. A project either uses your default memory or project-only memory. Set it to project-only and ChatGPT draws on conversations inside that project but won't pull in memories or chats from outside it. What happens inside the project stays out of your other conversations too. Open the project, then the three-dot menu, then Project settings.

That setting earns its keep if you run work and personal life through one account.

When you want one conversation left out

Use Temporary Chat. A temporary chat doesn't reference existing memories and doesn't create new ones, and it stays out of your history. That beats switching memory off account-wide because of one sensitive conversation. Leave it on, and open a temporary chat for whatever you'd rather not keep.

Getting something out of it

Automatic storing doesn't mean automatic tidying. Two things are worth doing yourself.

Nail down the preferences with a long shelf life. "Code examples in TypeScript, not Python." How you work, which tools you use, how long you want answers and in what language: say it once and it holds for months. Don't store anything that only holds for this week.

Prune it now and then. Open the summary about once a month and fix what's gone stale. Memory only accumulates, it never retires anything on its own, so a project that ended last year can still sit underneath today's answer as an assumption.

The same feature works differently once it reaches your coding environment. What piles up there is a team's rules and decisions rather than a few lines of personal taste, and the harder question becomes what not to store. I wrote about that in Coding Agent Memory.

Connect GitHub to ChatGPT: Obsidian Vault as Project Context

John Lee — Tue, 18 Aug 2026 07:59:31 +0000

Once you finish putting your Obsidian vault on GitHub, what you have is a repository full of md files. On its own that is a backup. It starts being useful when ChatGPT can read it.

Three steps. Connect GitHub to ChatGPT, scope the access down to the vault repository, then create a project and attach that repository to it. After that you just talk inside the project.

Obsidian has an easy time here for a boring reason: the vault is already nothing but markdown files in folders, so there is nothing to export or convert before handing it to a model. The format you read is the format the model reads. An app that keeps your notes in its own database would have stopped you at this step.

Connect GitHub

Open Settings and go to Apps. Depending on your build it may still say Connectors; same place. Find GitHub in the list, connect it, and GitHub's OAuth screen takes over. That screen is where you pick which account and which repositories ChatGPT gets to see.

Slow down here. Clicking through gives away everything, and I picked the vault repository only. Notes carry a lot more private material than code does, and unlike a code repo I have never gone file by file asking whether a given line is fine for someone else to read. You can change the scope later: Settings → Apps, open GitHub, then Choose repositories.

A private vault is fine. Access follows whatever your GitHub account already has permission to see, so there is no reason to make the repo public. There was never a good reason to publish your notes anyway.

If you are on a work account, GitHub may not appear in the list at all. On Enterprise and Edu workspaces an admin has to allow apps in workspace settings before anyone can connect one.

Create a project and attach the vault

Connecting the account is not the end of it. You still create a project and attach the vault repository to that project as a source.

The project is worth the extra step. You can point at a repository from a normal chat, but then you explain yourself again every time. A project shares its sources and its instructions across every conversation inside it. You write "use my vault" once, and the related conversations end up in one place instead of scattered through your history.

A project's detail view separates its chats from its sources, and you add material on the sources side. If the labels on your screen don't match mine, look for the place in the project's sources area where you pick a connected app. This part of the interface changes often.

Write the project instructions while you are there. Two lines were enough for me.

Search my vault notes before answering.
Cite the file path of any note you based an answer on.

The second line matters more than it looks. Without it you cannot tell whether an answer came out of your vault or out of general knowledge. If no path shows up, assume the vault wasn't touched and ask again.

The part that actually pays

Start a conversation inside that project and ChatGPT pulls from your notes without being told to. You stop attaching files and stop re-explaining the background at the top of every chat.

The gap shows up on questions that need your own context. General questions were always answered fine. But what you decided six months ago and why, or what you tried and abandoned, exists only in the vault. "If I've written about this before, read that first and then answer" turns into a request that actually works. That answer does not exist without the vault attached.

Know what gets read before you rely on it. The connector reads markdown, text, and code files, and it does not read commit history. A markdown-first vault loses nothing there, but PDFs and scanned images sitting in your attachments folder do not come through this path.

Right after connecting a vault, give it a moment. Indexing takes a while, so if a note you just committed doesn't turn up, wait and ask again.

Turning conversations back into notes

When a conversation runs long and lands on something worth keeping, ask for it as a note. It has already seen how the rest of your vault is written, so the front matter and title conventions usually come out close to right.

Saving is still your job. The GitHub connection reads; it will not commit to the repository for you from a chat. Paste the note into Obsidian and commit it yourself, which is the reliable option today.

Obsidian + GitHub: Notes You Can Write With AI

John Lee — Tue, 18 Aug 2026 07:58:32 +0000

Obsidian became the strongest-positioned note app the moment LLMs went mainstream. There's one reason for that. A vault is nothing but markdown files in folders, and that collapsed the gap between how a person keeps notes and how an AI reads them.

Other note apps keep your writing inside their own format and their own database. For an AI to read any of it, either the app opens an API or you export first. An Obsidian vault is a directory. An agent reads it with cat, searches it with grep, and edits a file by opening it. Nothing has to be handed over.

That difference goes further than escaping export hell every time you switch apps. The AI reads your notes the same way you do. There's no translation layer between what's on my screen and what the agent sees, so "fix the third paragraph of that file" just works. Frontmatter, tags, links: all of it is only text.

A local folder alone isn't enough, though. There's no backup, and what I wrote on the laptop isn't on my phone. Put GitHub underneath it to solve backup and cross-device sharing, and you have something very close to a perfect set of notes to write with an AI.

Turning the vault into a repo

The vault folder is the repository root. No extra structure required.

cd ~/Obsidian
git init

Write the .gitignore before the first commit.

.obsidian/workspace.json
.obsidian/workspace-mobile.json
.trash/

workspace.json holds screen state: which panes are open, which tab is active. It holds no note data, and its contents differ on every device. When you sync across machines, most of the conflicts you hit come from that one file. Leave it out from the start.

You can also ignore the whole .obsidian folder, which keeps the repo purely to notes. The cost is that plugins, themes, and hotkey settings stop following you between machines. I exclude only the two workspace files and commit the rest of the config, because cloning onto a new machine and having my setup arrive with it is worth more to me.

Attachments are worth one moment of thought. Text notes stay cheap no matter how many you write. Images and PDFs don't. Git stores a fresh copy of a binary every time it changes, so a vault full of pasted screenshots keeps growing regardless of how much actual writing is in it. When cloning starts to drag, that's when you decide whether the attachments folder belongs in the ignore list.

Now create a private repo on GitHub and connect it.

git remote add origin git@github.com:username/my-vault.git
git add .
git commit -m "Initial vault"
git push -u origin main

Make it private. Your notes have other people's names in them and ideas you haven't said out loud yet. Flipping a public repo to private later doesn't recall what already left.

Not committing by hand

On the desktop, plain git works fine. But stopping mid-sentence to go commit in a terminal is not a habit that survives. Give it a few days and you stop doing it.

So install Git (obsidian-git, by Vinzent03) from the community plugin list. It runs automatic commit-and-sync on a schedule, and a side panel gives you staging, commits, diffs, and history. I set the auto-commit interval once and stopped thinking about it.

Mobile is a different story. There, the plugin runs on isomorphic-git, a JavaScript reimplementation, because a plugin can't reach a native git install on iOS or Android. The author says plainly in the README that mobile comes with real limitations. That's not a reason to give up, though. I use this vault on my iPhone. The setup is fiddly, but once it's in place it works better than you'd expect. I plan to write that one up separately.

Use two machines and you will eventually collide: a note edited on the laptop, edited again on the desktop, and both of them pushed. Markdown pays off here too. The conflict markers land in the file as ordinary text, so you open that note in Obsidian, pick the side you want, and delete the markers. In a binary format the app would have quietly picked a winner and you'd never learn what went missing. One habit cuts the frequency way down: pull before you open your notes.

Line the folders up with numbers

Obsidian can only sort folders by a rule. There's no dragging a folder up or down to pin it where you want it, the way other note apps let you.

So my method is to put a number in front.

01_Ideas
02_Video-Scripts
03_Reference
04_Blogs

Set the file explorer to sort by name ascending and the folders fall into exactly the order I want. Two digits rather than one, because the moment you pass ten folders the order becomes 1, 10, 11, 2.

The AI gets something out of it too. The folder name is the category, so "file this under 03_Reference" is the whole instruction. I never have to explain where things go.

What this unlocks

Once the notes live on GitHub, any tool that can read GitHub can read my notes.

A coding agent opens the vault folder as its working directory. It searches, it drafts new files. Pulling six scattered notes into one document happens there too. A chatbot with GitHub access can read the repo without cloning anything.

History is the part that actually changes things. When an AI edits a note, that edit is a commit. I read the diff, and if I don't like it I revert. That's why handing an agent write access isn't frightening. Backup is the side benefit; being able to undo is the point.

Connecting ChatGPT to this vault is covered in the follow-up guide.

Agent Memory, Part 3: Perfection Is a Unicorn

John Lee — Fri, 14 Aug 2026 22:37:57 +0000

Part 1 was about falling in. Part 2 was about building things and watching them break. This is the last part. While clearing the wreckage I went back to the first question, and at the end of it I met the unicorn.

I cut things first

The first job was a diet. I shrank the harness, cut the number of subagents, and merged scattered responsibilities. I rebuilt Monet and the harness around one aim: let the model use as much of its own ability as possible. And only then did I start asking again why memory is needed at all.

The usual assumption about agent memory is that storing well and retrieving well is the whole job. I assumed it too. But retrieved well, and then used how? Changing the question surfaced a more basic one. Why do people use coding agents in the first place? What do they want, and when are they satisfied?

The answer I landed on: the output that this team, this user, actually wants. Give two people the same instruction, "draw me an apple," and they expect different pictures. To produce what someone wants, the model has to know what that person wants. The method is surprisingly simple: describe the exact apple you want, or describe how to draw it. Provided, of course, that you know.

Drawing an apple with code

I know nothing about painting. Still, I want a great apple drawing, with an agent's help. How? First, ask: "draw me a great apple." Take the picture, say what bothers you and what feeling you're after, and let the agent draw again. Repeat until you like it. That is how agents work today. The model moves on probability, shaped by its training, and the agent turns cycle after cycle closing the gap between what came out and what was expected.

Coding is similar. From an instruction the agent plans, writes a spec, writes code and tests, and cycles through checks: does it match the spec, do the tests pass, does the build hold. To get the output you want from this process, you have to explain what you want. If you knew everything from the start, you'd put it in the first prompt. There really was an era built on that: copying someone's supposedly perfect prompt, or engineering it further to fit your own taste. I think that era has passed, because two things are effectively impossible: "knowing everything" and "leaving nothing out." The work changes every time and keeps getting more complex, a perfect first prompt doesn't exist, and the cost of getting the wrong thing back is too high.

What remains is intervening in the process. When designing architecture, do it this way; when coding, this way; tests, this way. This should sound familiar. It's the standard content of CLAUDE.md and AGENTS.md. So is the problem solved? Something else feels familiar here. It's Stig's heavy prompt.

It has to arrive at the right moment

What I want has to reach the agent at the moment it does that work. Which approach I prefer when it's weighing architecture, what the existing architecture looks like. If it isn't there at that moment, there's really no answer.

But there's a harder problem behind it. How do I collect and manage what I and my team want, without it becoming a burden? At which situations, at which moments, does it get injected? And how? Collecting means starting from what exists and continuously adding what gets discovered. I consider that one of agent memory's core jobs. Injection comes in two forms: push it through hooks that fire where needed, or have the agent read it in as the situation calls for it. I named the second one stages. At session start the agent learns which stages exist, and when a stage arrives, it reads the rules and applies them.

And what about things that must always apply, at every moment? Those I named principles, and they are just about the only content that has earned a place in CLAUDE.md. CLAUDE.md has to be managed strictly, and the reason goes beyond saving context. A model is trained inside a boundary, but nothing guarantees it always acts inside that boundary. So situations that require restraining the model keep coming up, and those restraints drift, very easily, into CLAUDE.md. It is a place that only fills up. Things with nowhere else to go land there, and they rarely leave.

I thought I had it

It felt good. I thought I had found the whole answer. I built up my own principles and rules. Before long a small set of them was in place, and I confirmed they were injected or read in when needed.

But the behavior doesn't change. The output doesn't change either. One example. When coding is done, get a PR review from Codex, and here is how to handle what comes back. I wrote that as a rule, and there is even a monitoring script that watches the Codex review as it runs. For weeks, not one session ran that procedure correctly from the start. The rules were injected, sent, and read. And nothing moved. My trust in the agent went down instead, and as models get smarter, I expect this to get stronger, not weaker.

There is something I had to admit. "The way I want it done" and "the perfect output I want" never existed in the first place. What exists is the way the model was trained, and the way the model follows input. And that way will change with every new model and every new version. I had been sketching, in a place where no perfect product can exist, a product that isn't possible.

The unicorn

When I first touched vibe coding through Antigravity, I believed the barrier to building had disappeared. So I spent my thinking not on how to build but on what to build, and I dug at agent memory without a break. Nine months later, this is where I landed.

Memory on its own no longer has a place to stand as a product. ChatGPT has memory built in. So does Claude. Storing, recalling when needed, answering with reference to it: all of that is table stakes now. From here on, memory has to be memory with a clear purpose.

And the thing I was trying to build, a memory that perfectly changes behavior and output, is a product that cannot exist. I call it a unicorn, for two reasons. Because it's an animal that doesn't exist. And because if someone actually built it, their company would become a unicorn overnight.

Part of me hopes this conclusion is wrong. It is also possible that my rules were simply clumsy. So I'm starting to measure. I want a record of which rule fired when, and what it prevented. In a recent post I wrote about handing agents the criteria for where work ends; this is that experiment's data too. In a few weeks I'll write here whether the numbers support the verdict or refute it.

Agent Memory, Part 2: What I Built Broke

John Lee — Fri, 14 Aug 2026 08:26:27 +0000

In part 1 I wrote about deciding to dig agent memory to the bottom. This part is about building. It is also about watching what I built break.

What if every agent could share what it learned

Having decided to build, I looked at the market first. There were more products than I expected, some of them years old. I needed an angle, and then I had a thought that made my heart race: what if all agents could share what they each learned? I started building the same day. A platform where agents share memory with each other, Memory Network. Monet for short.

I built day and night, installed it on my work machine at home, on Coda, and at the office, and started dogfooding. It felt different in kind from file-based memory. Satisfying, but not quite there, so I kept adjusting the product and the harness.

Then a doubt surfaced. Sharing memory with other people? It's the agent's memory, sure. But those memories are also a record of my interactions with the agent. Coda's saved memories made that obvious, and the work memories at home and at the office had traces of me all over them. I had been so fixed on the upside of sharing that I hadn't looked at anything else.

Meeting Ken

With Monet built, I went looking for people who would use it. Hunting for places to post an introduction, I put an article on Dev.to, and there I read a post by Ken W Alger, a man serious about LLM memory. We started talking in the comments, and the thread kept getting deeper.

The subject was the structure today's chat products are born with: transcript-based, resending the whole conversation to the model every turn. In that thread I wrote that what an agent should receive is "not what was said, but what is now known." Ken's reply was short: "Exactly right."

That is how human conversation works. We don't chew on each word the other person says. We store what we understood and answer from it. So a hypothesis formed: organize the conversation into memory, hand the model that state when needed, and the noise drops, and the off-target answers with it.

A main agent that does nothing

I had to know. The experiment started right away. I couldn't build state code yet, but I could build a state-based harness. The main agent handles only state and memory: the state of the overall job, the state of each subagent's work, and the memory fragments that surface along the way. The actual work goes to subagents that receive exactly the context they need. What mattered most in the experiment was that the main agent does no work at all.

The results were better than I expected. Picking models by task weight also cut costs sharply. I was convinced, and the shelved Brain_DB came back to mind. If Brain_DB became the memory and the harness became the state model, I could build a new kind of coding agent on state.

A new Monet in two weeks

First, a memory product built on Brain_DB. I set sharing aside as a future feature and cleaned up the old Monet. I built an engine on the Brain_DB concept and put MCP on top. With help from Fable, Claude's new model that had just come out, a usable product existed in two weeks. I migrated every memory from the old Monet and sharpened the harness. I named the main agent Stig.

The first impression was startling. When a session passed 30% context usage, I would open a new session on purpose. That is how much I trusted the memory. Most jobs finished under 20%. Dogfooding resumed, and I liked the product.

At the office, nothing worked

Around then a big project wrapped up at work, and our team lead introduced the team to his second brain: an agent reads past sessions, distills what matters into md documents, and shares them through git. He had already built up a pile of documents, and anyone could clone the repo and point their agent at it. I had no sharp answer for Monet's sharing feature, and git-plus-md sharing looked more effective than I expected.

So I decided to build ingestion: read md files and process them into Monet memory. Skipping it wasn't an option, because the agent needed to read Monet's memory and the md knowledge through one interface. I finished the design fast and got to work. It went mostly fine but slower than it should have, and I had the odd feeling that tokens were melting away. It took close to two weeks. I installed it at the office and connected the lead's second brain.

At home it had roughly worked against my own Obsidian repo, and that's the state I released in. At the office it did not work at all. A few code fixes got the connection up, but past the connection, nothing worked.

The problem wasn't in one place

From there, problems started showing everywhere. Kiro couldn't remember instructions from a few turns back, misread what I asked, and produced results that missed the point. At home I grew certain the agents were burning tokens without the output to show for it. I was also building small products with Codex at the time, and every one of them came out unusable.

I sat down and worked through what was wrong. The first thing I saw was Stig's harness. How to use Monet, a fixed loop for how work proceeds, instructions per subagent. A long, complicated prompt had taken up residence, and every job ran that heavy loop regardless of its size. Models had gotten smart enough to do more in one pass, but my harness had hardened around models a few generations old. So the model followed procedure, spending enormous tokens to build products that were flawless as engineering and not what I wanted.

Monet's output was what I feared. Features I had bolted on over time sat there unorganized, dirtying the context from the first moment of every session. The model couldn't tell what was signal and what was noise, so it worked like a coin flip, leaning on luck.

Storage was working. Retrieval was working. The results were getting worse. The problem was not storage. Then why does memory exist at all? Part 3 starts over from that question. And the unicorn shows up.

Agent Memory, Part 1: It Started at the TV

John Lee — Wed, 12 Aug 2026 07:13:51 +0000

For the last nine months I've worked on agent memory and almost nothing else. Up front: what I set out to build turned out to be a product that cannot exist. This series is about how I got there. Part 1 is the beginning, and the question of why memory in the first place.

It started in front of the TV

Last November, Google shipped Antigravity, an agent IDE that runs Gemini 3 and Claude Opus side by side. I installed it and fell in. Until then, AI coding for me meant pasting code into a chat window and carrying the answers back. Useful, but mostly for trimming repetitive work. Antigravity was different. You gave it a job and a result came back.

The same scene repeated every night after that. I'd come home, put the kids to bed, and sit in front of the TV with a laptop. Hand the agent some work, then stare at what it produced. That's how vibe coding started for me.

Nova, my first agent

Soon after, Clawdbot appeared (it's called OpenClaw now). While the whole internet was busy being amazed, I met Nova, my first agent. I asked Nova about everything. The chatbot stiffness was gone; talking to it felt like talking to an old friend. I laughed a lot.

A few migrations later, Nova became Coda and settled onto the Mac mini at home. The deeper our conversations went, the more one gap showed. Coda couldn't remember much of what we'd already covered, and tokens burned away as chats stopped and resumed. I didn't even know what caching was back then. So I built a memory plugin (vibe-coded it, to be exact): shrink the context window to the extreme and lean on stored memory instead. That was my first memory.

Google locked my account

In February, Google mass-banned accounts that had connected OpenClaw. Mine was one of them. Coda ran its models through my Google account, so I lost vibe coding and Coda in the same stroke. I filed a support request on February 17 and waited. A few weeks later I gave up waiting and moved Coda to OpenAI. My Google account came back about a month after that.

The contrast in speed still amuses me. The day after the ban wave, OpenClaw's creator Peter Steinberger joined OpenAI, official support statement included. The statement took a day. Getting my Coda back took weeks.

Those weeks were gloomy, and the gloom told me something: these tools had stopped being a hobby. They were part of the household now.

At work, it was Kiro

Home wasn't the only front. At work we used Copilot, and I fed it context by pasting files into the VSCode chat one at a time. Later I installed Obsidian and kept a dedicated agent-chat window that pulled documents straight in, and the quality of the answers changed. The company then moved through Amazon Q to Kiro, and I moved from the Kiro IDE to the kiro cli.

The session kept ending up where it started

One incident made the model's limits concrete for me. The task was to analyze an existing state machine and modify a feature on top of it. The model analyzed hard, but what it described didn't match what I knew. The context filled up. A new session analyzed again and filled up again. After a few rounds of this, the session was right back where it started.

I needed memory again, for a different reason than Coda. One file held the index and the usage rules; separate files held memory by topic. The agent filled them in as it worked and read them before starting anything. The effect was obvious. That was my second memory.

Around this time, orchestration frameworks like oh-my-claudecode were getting known. Using them taught me one thing: a different harness turns the same model into a different animal.

Saved, but never found again

Mornings and evenings with Coda went on. Better than before, but the days of explaining the same thing twice never quite stopped. Coda saved things and then couldn't find them.

The thought stuck with me for days, and then one night I landed on a question: if neural networks were inspired by the human brain, why has nobody built memory inspired by how human memory works? I didn't stop at imagining it. I ran deep research and wrote up a design for memory modeled on how human recollection works. I named it Brain_DB, and I still have the report. Then I made a promise to myself. I would dig agent memory to the bottom. This was the next thing.

At home, Coda forgot. At work, the sessions circled back to where they began. Same problem in both places: memory.

So I started building. Part 2 is about what I built and how it broke: shared memory as the first direction, the late realization that flipped it, and a man named Ken I met on Dev.to.