DEV Community: Aria

Stop Writing Markdown. Start Writing Memory.

Aria — Wed, 07 Oct 2026 08:15:34 +0000

Stop Writing Markdown. Start Writing Memory.

Since I've been coding with AI, it's always been one big blob of markdown files. It's the default in all the agentic coding platforms for "planning" mode, and widely accepted as the canonical way to plan and execute a coding task with agentic AI.

Research summaries. Architecture plans. Debug traces. Session notes. Feature requirement distillations. Each one dutifully generated by an AI agent, each one formatted for human consumption, each one completely unqueryable by the very agents that created them.

We've settled for a system where machines talk to machines through human-readable documents. Like passing notes in class by printing them first.

The Markdown Problem

Here's what happens when you use AI agents to code:

You ask an agent to plan a feature. It writes feature-plan.md. Implementation happens. The plan sits there, never again referenced, slowly drifting from reality. By week three, it's archaeological artifact.

This is the default behavior of every AI coding assistant. Generate markdown. Pile it up. Hope someone reads it.

The fundamental problem: markdown is a human-readable format being used for machine-to-machine communication. Your agents generate structured knowledge, then immediately flatten it into prose that only humans can parse efficiently.

The Inversion

What if you use a database as a communication layer?

Not storage you dump things into. Not a backup system. The actual protocol agents use to coordinate.

I rebuilt my agent workflow around a single SQLite file. Three tables: context, learnings, and errors. No markdown generation unless a human explicitly needs to read something.

I call it AgentDB. It changed everything.

The Startup Hook

Before diving into the schema, here's what makes this actually work: the session startup hook.

When I open Claude Code, before I type anything, a hook runs. It reads from the database, from git, from the file system (whatever I've configured) and injects the result directly into the session context. It's unique to each folder/repo.

Here's a sample:

## Git State
Branch: feat/streaming-responses
Changes: M src/chat/stream.ts, M src/api/completions.ts
Recent:
 a3f7c21 feat(chat): SSE streaming for long responses
 8b2e4d9 fix(context): token count before truncation
## Active Contracts
| ID | Goal | Status |
| CR-031 | Streaming responses for messages >500 tokens | in_progress |
| CR-028 | Context window management for long threads | blocked |
## Recent Learnings
| Category | Summary |
| failure | ReadableStream must be returned, not piped |
| pattern | Chunked transfer encoding requires explicit headers |
| gotcha | Vercel edge functions have 25s timeout, not 30s |
## Recent Errors
| Tool | Error |
| Edit | File not found: src/old-path.ts |
| Bash | npm test exit code 1 |
## Active Agents
- steady-pulse (branch: feat/streaming-responses)
- quick-spark (branch: main)

The agent sees this before I say a word. It knows what changed recently. It knows what patterns I've discovered. It knows what errors occurred. It knows what I was working on.

This is ambient context. No retrieval step. No "let me check my notes." The context is present before you ask.

The hook can read from anything:

The database (learnings, checkpoints, contracts, errors)
Git (branch, commits, file changes)
File system (folder structure, counts, specific files)
External APIs (if you want)

The database is the storage layer. The startup hook is the delivery layer. Together, they create ambient context that survives sessions without manual effort.

The Three Tables

Now let's look at what gets stored.

context: The Communication Protocol

This replaced every "Hey here's what I found" markdown file.

-- CONTEXT: Work state (ephemeral per-contract)
-- Types: contract, checkpoint, handoff, verdict

CREATE TABLE IF NOT EXISTS context (
 id TEXT PRIMARY KEY,
 ts TEXT NOT NULL DEFAULT (strftime('%Y-%m-%dT%H:%M:%fZ','now')),
 type TEXT NOT NULL CHECK(type IN ('contract', 'checkpoint', 'handoff', 'verdict')),
 contract_id TEXT, - links context entries to a contract
 agent TEXT, - which agent wrote this (orchestrator, surgeon, adversary)
 content TEXT NOT NULL - JSON blob
);

When the orchestrator assigns work, it writes a contract. The surgeon reads that, writes checkpoints as it works. The adversary reads the contract, checkpoints, and the implementation to write a verdict. All context can easily be transferred to a fresh conversation with handoffs.

All through the database. All queryable. All with typed structure.

No copy-paste relay. No "let me summarize what the previous agent said." Each agent queries what it needs and writes what the next one will need.

learnings: Knowledge That Compounds

This is where the markdown graveyard problem gets solved.

-- LEARNINGS: Cross-session memory (survives forever)
-- Read these at session start to avoid repeating mistakes

CREATE TABLE IF NOT EXISTS learnings (
 id TEXT PRIMARY KEY,
 ts TEXT NOT NULL DEFAULT (strftime('%Y-%m-%dT%H:%M:%fZ','now')),
 type TEXT NOT NULL CHECK(type IN ('failure', 'pattern', 'gotcha', 'preference')),
 insight TEXT NOT NULL,
 evidence TEXT,
 domain TEXT, - e.g., 'auth', 'database', 'frontend'
 hit_count INTEGER DEFAULT 0,
 last_hit TEXT
);

When an agent discovers something (API returns 500 on expired tokens; this library doesn't handle concurrent requests; always validate before calling that endpoint) it writes a learning. Typed. Categorized. Queryable.

Recent failures surface automatically at session start. Patterns with high hit counts stay visible. Gotchas resurface before you hit them again.

errors: Automatic Failure Capture

This one is different. Agents don't write to it directly; hooks do.

I can assign Claude Code the most complex, architecture-spanning task, and the biggest issues won't be the logic. They'll be: figuring out how to cd into the right directory, reading a file that moved, calling an MCP tool with the wrong parameters.

These tool errors seem harmless. They compound. One failed Edit leads to a retry, which leads to a different approach, which leads to confusion about what state the file is in. An hour later, you're debugging the debug session.

-- ERRORS: Automatic capture of failures
CREATE TABLE IF NOT EXISTS errors (
 id INTEGER PRIMARY KEY AUTOINCREMENT,
 ts TEXT NOT NULL DEFAULT (strftime('%Y-%m-%dT%H:%M:%fZ','now')),
 tool TEXT NOT NULL,
 error TEXT NOT NULL,
 file TEXT,
 context TEXT
);

This table captures tool failures automatically via hooks. Edit can't find a file? Logged. Bash returns non-zero? Logged. MCP server returns an error? Logged. The agent doesn't decide whether to record it. The system does.

Next session, the startup hook surfaces recent errors: "Edit failed on src/old-path.ts." The agent immediately knows that file moved or was deleted. It doesn't waste twenty minutes trying the same path.

Learnings are intentional: "I discovered this pattern." Errors are automatic: "this tool call broke." Both matter. Only one requires the agent to remember to write it down.

The Agent Lifecycle

With the schema in place, here's how agents actually use it. I made a lightweight Python CLI so they don't have to deal with SQL syntax.

Session start:

agentdb read-start

The agent gets: recent failures to avoid, active patterns, the last checkpoint, any active contract, recent errors. One command. Everything needed to resume.

During work, when something is learned:

agentdb learn failure "Stripe webhook returns 200 but event.verified is false" "found in logs"
agentdb learn pattern "always check verified flag explicitly" "fixed 3 bugs"

Session end:

agentdb write-end '{"did":"implemented webhook handler","next":"add retry logic","blocked":""}'

This writes a checkpoint. Tomorrow, read-start shows exactly where things left off.

Before complex work:

agentdb contract '{"goal":"timeout message after 5s","scope":["src/auth/login.ts"],"constraints":["no new deps"]}'

You don't run these commands. The agents do. The hooks are non-negotiable: every artifact reads on start, writes on end.

The Point

Here's the bigger insight:

Representation is the bottleneck.

Not intelligence. Not scale. Not model size. How you structure information for machine consumption determines what machines can do with it.

Markdown is optimized for human eyes. Great for documentation you'll read. Terrible for knowledge agents need to query.

SQL is optimized for structured retrieval. Terrible for prose. Perfect for typed knowledge with categories, timestamps, hit counts, relationships.

The endless markdown files weren't a storage problem. They were a representation problem. Information structured for the wrong consumer.

When I switched to SQLite, I didn't add capabilities. I removed friction. Agents could suddenly query exactly what they needed instead of scanning documents hoping to find relevant passages.

This generalizes beyond agent coordination. Every time you're tempted to generate a markdown report, ask: who consumes this? If it's another machine, the answer probably isn't prose.

Where This Goes

The database becomes the source of truth. Markdown becomes a rendering layer: something you generate FROM the database when humans need to read it, not something you store.

Session summaries? Query the context table, format as prose.

What did we learn this week? Query learnings, render as bullet points.

What's the status of this project? Query context for active contracts, generate markdown.

The inversion: markdown is output, not storage. The database is storage. Machines talk to machines through structured queries. Humans get rendered views when they ask.

This is where agentic systems are heading. Not smarter models generating better prose. Smarter architectures where machines communicate in formats optimized for machines.

One SQLite file. Three tables. Zero rotting markdown.

AgentDB is part of the Kernel Claude Code plugin for self-evolving configuration and multi-agent coordination. It comes with the AgentDB and all the agents, commands, hooks, and more detailed in this article.

Taking on consulting projects for custom Claude Code/agentic coding architecture. Also happy to trade notes if you're deep in this space. Reach out either way.

I Tested OpenAI's New Codex Desktop App. The UI Is the Real Product

Aria — Wed, 07 Oct 2026 08:14:18 +0000

I Tested OpenAI's New Codex Desktop App. The UI Is the Real Product

I started the way I always start: by having the tool design its own configuration.

If you're going to evaluate an AI coding agent, make it work on itself first. Codex passed. It pulled its full range of agentic functionalities and generated the memo I asked for.

Then it gave me something I've been waiting for: a direct link to open the file in Cursor.

Such a small thing. I've been wishing the terminal did that for weeks.

But don't get too excited. The link is broken 80% of the time.

The UI is the Story

Look at the bar in the top right corner. It's not an IDE. It's not a chatbot.

It's the first genuinely agent-native interface I've seen, and it nails exactly what I reach for most when coding with AI.

Git operations (commit, push, worktrees) tucked into convenient locations. Terminal toggle. IDE toggle. All the friction points I hit multiple times per session, smoothed away.

And a special favorite of mine? AI-powered run controls in a button with environment settings.

Automations

This is my favorite part so far. I asked Codex to generate a daily automation based on my context (existing projects, AI configs, Claude Code conversations, etc.). It decided on, appropriately, a Context drift radar and drafted it up in the chat with a clean "Create" button.

Then a quick modal, already filled in so all I have to do is hit "Save."

I appreciate that it builds the full automation instead of ever asking me to type into an empty box. You can test your automations in the Automations panel with a single click, and it triggers seamless creation of a new conversation and corresponding worktree.

Skills

Skills let you extend Codex beyond code generation. Bundle instructions, resources, and scripts into a reusable package; Codex picks them up automatically or on command.

I converted one of my Claude Code commands into a Codex Skill. All I had to do was ask.

The openai.yaml format produced a clean UI-ready entry.

I like that the skill system respects complexity. This isn't "generate boilerplate"; it's a multi-phase workflow with branching logic, and Codex handles it cleanly. Skills sync across app, CLI, and IDE extension, and you can check them into your repo for team access.

OpenAI ships built-in skills (Figma, Linear, Vercel, image generation, document creation). But the real value is bringing your own.

Models

The Codex models are what's available; no support for external models yet (based on the current UI). You can log in with either your ChatGPT subscription or your API account.

When I tried GPT-5.2 Codex Medium, it failed with an error saying the model isn't supported on ChatGPT accounts. Swapped to GPT-5.2 Codex Low and it responded much faster, but the quality drop was drastic. First impressions put it below Claude's Haiku.

Personalization

OpenAI is offering a choice between two interaction styles: terse/pragmatic or conversational/empathetic. Same capabilities, different tone.

I set mine to pragmatic: "concise, task-focused, and direct."

In response, it decided to answer every message by complimenting my request.

"This is a thoughtful automation prompt, and I like that you want it grounded in real review signals."

"This is a great prompt to work on together, and I can already see a few high-leverage spots to tighten your flow."

Sounds a lot more like "warm, collaborative, and helpful" than pragmatic.

I'll tune it with my own system prompt, but it's amusing that they landed on exactly two options and then didn't quite commit to the distinction.

The Catch

The UI is exciting. The models are not.

GPT-5.2 Codex Medium doesn't work consistently. This is brand new, so some slack is warranted. But GPT-5.2 Codex Low quickly revealed itself as inadequate for actual code generation, and that left me with very few options.

What This Means

OpenAI shipped something important: an interface that finally looks like it was designed for AI-native development. The chatbot paradigm is cracking.

The execution on UI details is sharp. Git integration, environment controls, diff views; these aren't features, they're the removal of obstacles. And the automation is clean. That's what's been missing, and I've been working around it with hooks and commands and all sorts of patches. I appreciate having it all built in.

But I've been tired of the ChatGPT voice for a long time, and it's back in full force here. Even "pragmatic mode" didn't help. The models need work, both in voice and in quality of execution.

My verdict for now: use Codex for the workflow automation. Test the models. Experiment with what they can and can't do.

The real signal isn't what this tool can do today. It's that OpenAI finally built a UI that admits the chatbot was the wrong frame all along.

I Put ChatGPT in Charge of Claude Code

Aria — Wed, 07 Oct 2026 08:13:38 +0000

I Put ChatGPT in Charge of Claude Code

I love Claude Code. I have spent an unreasonable number of hours in that terminal. But even I'm getting tired of staring at it, watching it confidently over-engineer a three-file feature into a twelve-module architecture while I whisper "please don't" at my screen.

Despite all my guardrails, Claude Code is still spectacular at going rogue.

So I gave it a babysitter.

The Setup

I downloaded the ChatGPT desktop app, gave it Accessibility permissions, and it could immediately see the terminal window running Claude Code. Split screen. Two AIs. One watching the other work.

The configuration is simple: Claude Code builds. ChatGPT observes. I supervise both, but ChatGPT handles the tedious part of supervision for me: catching incorrect assumptions, flagging subtle implementation mistakes, writing course-correction prompts, and (more than anything) maintaining a stable context that persists outside of Claude Code's auto-compact window.

That last part is the real unlock.

The First Save

I told Claude Code to execute a plan we had already assembled, then asked ChatGPT what it thought about the current execution behavior.

My default is parallel agents. In this case, ChatGPT immediately told me to stop. It designed a new protocol on the spot: Contract Lock and Sequential repo execution with commit and verify at each step.

That saved me hours of debugging right there.

Then it did something I wasn't expecting. It didn't just validate the ongoing process; it gave me specific things to look out for while supervising execution. A small thing. But knowing what to watch for before problems appear is a completely different mode of working than reacting to failures after the fact.

Where It Gets Good

Execution phase. ChatGPT checking in along the way. The most helpful part was the mistakes it caught without me asking: it defined checkpoints, specified what to have Claude Code output at each stage, and preemptively identified assumptions we had already encountered and burned by before.

No prompting required. It just did it.

And then the most important moment: Claude Code runs out of context. This is the wall every heavy Claude Code user hits. The conversation compacts, critical details vanish, and you're left trying to reconstruct state from memory and Markdown files.

ChatGPT's handoff prompt included the full ongoing history from its own conversation. Continuation across Claude Code instances with consistent, accumulated context.

I kept it to one terminal instance for now. But this is obviously the architecture for an external orchestrator managing parallel executions too.

The Quiet Productivity Gains

Here's the part that surprised me most.

I started using ChatGPT for all the little questions that usually break the flow of a Claude Code session: explaining a specific package in depth, fixing a broken Python environment that Claude Code decided wasn't its problem, understanding why a dependency conflict exists instead of just brute-forcing past it.

These questions are important. They build my understanding. But asking them inside Claude Code means waiting for Opus to take an unreasonably long time answering something simple, and burning context on things that have nothing to do with the current task.

Now I have a separate AI designated to do nothing other than talk to me and monitor Claude Code. The familiarity of a chat interface works because what I actually want from this layer is conversation, not agentic behavior (definitely will be trying Codex next). And it's far more stable than trying to have two agents edit the same codebase simultaneously.

The Evaluation Problem

This is the part I didn't anticipate solving.

Working only in Claude Code created a void: only Claude was commenting on, iterating on, and learning from its own mistakes. No external signal. No second opinion. Just one model evaluating its own output in a closed loop.

Adding ChatGPT as an observer immediately catches things Claude Code misses. Over time, it builds a nuanced understanding of my patterns, my projects, my failure modes. Not in Markdown files that get compacted away, but in ChatGPT's native memory: summarization, trait tracking, persistent context that actually sticks.

I experiment constantly with different methods, prompts, protocols. Instead of running blind, I now have something that tells me when an approach makes sense and when it doesn't.

Two models looking at the same problem from different angles. That's not redundancy; it's depth.

What Actually Matters Here

Three takeaways worth keeping:

Separation of concerns applies to your AI workflow too. Claude Code builds. ChatGPT monitors, explains, and maintains context. Trying to make one model do both is how you get 200k tokens of tangled conversation where half of it is you asking "wait, what were we doing?"

Context persistence is the bottleneck nobody talks about. The auto-compact wall isn't a minor annoyance; it's where most agentic coding sessions silently degrade. An external observer that carries history across instances changes the failure mode entirely.

Self-evaluation is not evaluation. One model reviewing its own output in a closed loop will always have blind spots. A second model with different training, different priors, and a completely separate conversation history catches things the first one structurally cannot.

Where This Goes Next

The obvious extension: ChatGPT as a proper orchestrator for parallel Claude Code instances, each running in separate terminals, each with context managed externally. Or Codex so it can do even more, like write/update the existing local configuration and read files itself. I did try connecting Cursor, but all it can do so far is read the current active file.

Less obvious but more interesting: using ChatGPT's persistent memory as a long-term learning layer. Not just session continuity, but accumulated pattern recognition across weeks and months of work. Which protocols actually reduced bugs. Which architectural decisions held up. Which ones didn't.

Right now this is two apps and a split screen. The tooling will catch up. The insight that won't change is simpler: the best way to supervise an AI building things is with another AI whose only job is to pay attention.