DEV Community: Edward Izgorodin

Workflow intelligence ships as a primitive

Edward Izgorodin — Mon, 29 Jun 2026 13:31:06 +0000

This past week, OpenAI shipped Record & Replay for Codex.

Show Codex a workflow once. It turns the demonstration into an inspectable, editable skill that can guide similar work later through Computer Use, browser actions, and installed plugins.

Anthropic moved in the same direction through a different architecture: agent teams, composable skills, and nested subagents in Claude Code.

Two stacks. Same week. Same shift.

From research conversation to shipped primitive

The thing that was a research conversation last month and a procurement decision last week is becoming a shipped primitive.

In the OpenAI version:

record a workflow
extract the repeatable procedure
save it as a callable skill

In the Anthropic version:

describe a skill
load it into specialized agents
compose agents and skills into a larger workflow

One learns from demonstration. The other composes explicit procedures. Both move the unit of work up a level.

Workflow intelligence as a product

You are no longer only wiring tools to prompts. You are encoding how work is actually done and making that procedure callable by agents.

That is workflow intelligence as a product.

And it sharpens the ownership question.

Who owns the recording, the corrections, the exceptions, and the accumulated procedure the agent inherits?

The vendor? Or the builder?

What the Cursor deal may have been pricing

Perhaps that is part of what the Cursor deal was pricing.

Not only the editor. The workflow layer around it.

If memory was part of what last week's procurement conversation was about, workflow intelligence is what this week shipped. The two layers are arriving as products around the same time, and the ownership question follows them both.

Originally posted on LinkedIn on June 22, 2026 — Edward Izgorodin.

Related: Memory is becoming a procurement decision (last week's piece on the same arc).

More research on AI agent memory and workflow intelligence at mnemoverse.com/docs/library. I build Mnemoverse, open-source persistent memory for AI agents.

Memory is becoming a procurement decision

Edward Izgorodin — Mon, 22 Jun 2026 17:44:11 +0000

Last week: $60B for Cursor, where the deeper asset was not just the editor, but workflow memory around engineering teams.

Recently: Anthropic previewed "dreaming" for Managed Agents. Google's Memory Bank in Vertex AI and Agent Engine points in the same direction.

Different architectures. Same shift.

Persistent memory has stopped being only a research conversation

It is becoming a procurement decision.

For builders, this changes one thing.

You no longer get to defer the memory layer choice.

Either you pick a cloud vendor's memory and inherit its abstractions: what state means, what consolidation means, how revision works, and who controls the memory surface.

Or you pick an open layer and keep those architectural decisions inside your own stack.

Both are valid. They produce very different systems.

The uncomfortable question is what gets priced next

Is it only IP, product, and distribution?

Or is it the accumulated understanding of how teams actually get work done with agents?

Not raw user data in the crude sense.

Something more strategic: repeated workflows, corrections, repo context, task patterns, and intent signals transformed into an agent's ability to understand the job.

The vendor or the builder

If memory was part of what the market priced last week, the question now is who controls it.

The vendor.

Or the builder.

Originally posted on LinkedIn on June 19, 2026 — Edward Izgorodin.

Related research on AI agent memory at mnemoverse.com/docs/library. I build Mnemoverse, open-source persistent memory for AI agents.

Agent memory is not a database

Edward Izgorodin — Thu, 18 Jun 2026 20:49:55 +0000

A paper from late May argues that agent memory is not a database. I think it is right.

That sentence is the entire thesis. The rest of this post is what it means.

The four failure modes

Orogat and Mansour name four failure modes you hit when you treat memory like storage:

Unregulated growth — facts pile up indefinitely with no shape control
Missing semantic revision — the system cannot update what a fact means over time, only the row itself
Capacity-driven forgetting — you forget the wrong things first, because storage limits decide for you
Read-only retrieval — retrieval cannot reshape state; reading is decoupled from learning

If you have built a serious agent, all four are familiar. They are not edge cases. They are what happens when the abstraction is wrong.

GEM — four state-level operations

The authors' model, Governed Evolving Memory (GEM), replaces record-level CRUD with four state-level operations:

Ingestion — incorporate a new observation into memory state
Revision — update what existing memory means, not just its contents
Forgetting — explicit, governed reduction of state
Retrieval — read-coupled-to-state, not detached lookup

Notice what is missing. There is no insert. No update. No delete. The operations are about the state of memory, not the rows in it.

The strongest claim

Then they make the strongest claim in the paper:

No record-level system can satisfy the correctness conditions, whatever storage engine sits underneath.

That is the part worth sitting with.

The claim is not that databases are slow. It is that the abstraction is wrong. Correctness lives in how memory state evolves over time, not in any single record.

For anyone building long-running agents that are supposed to remember, this reframes the design question.

Less: "What is the right schema for memory rows?"

More: "What is the right vocabulary for memory state evolution?"

The honest gap

The prototype runs on a property graph, and the authors are honest about the gap: state-level revision and forgetting are expensive to do properly. Native engine work is still ahead.

Worth reading

A short paper. Worth reading if you build for agents that have to remember.

📄 Paper: arxiv.org/abs/2605.26252

Also shared on LinkedIn — Edward Izgorodin, June 11, 2026.

Related research on AI agent memory at mnemoverse.com/docs/library. I build Mnemoverse — open-source persistent memory for AI agents.