Humans Own. AI Assists. The Graph Remembers.
There's a rule going around AI-native engineering teams right now that I think is mostly correct and almost completely under-applied.
@vovacodes at @SquadsLabs put it most clearly in his article :
Every PR has a single human owner. AI may assist. AI never counts as ownership.
I agree with the rule. But the part that actually matters isn't the rule itself, it's the reframing. Instead of asking “How do we use AI to make each engineer faster?” the better question is “How do we use AI to make every engineer think like the whole team?”
Once you internalize that reframe, you can't stop seeing it everywhere. The problem it's solving in engineering isn't really an engineering problem. Senior judgment is finite and can only cover the work that made it through a thorough review. It's a scarcity-of-context problem, and the place it hurts most isn't code, it's everything that happens outside the repo.
Where Human Ownership Breaks Down
In my last article, we talked about Engram as a collective memory graph for 18 agents working across five codebases. TL;DR- Incorrect imports. Parallel drift. Rediscovered bugs. The kind of pain you get when every agent starts from zero.
We fixed that. Agents stopped hallucinating our own systems. Knowledge started compounding. The velocity high started converting into actual altitude.
But six weeks in, I noticed we'd only solved half the problem. The engineering side had a memory graph. My side, the founder side, didn't.
I'd walk out of an investor call with three offhand comments that would change our roadmap, and by the next Monday only half of them had made it into anyone's brain. A merchant would explain, in painful detail, exactly why they'd ripped out Square. Two weeks later an agent would design a feature that solved the wrong problem because nobody had written it down. I'd have a 45-minute strategy call with Niko on a walk, hang up, and realize the most important decision we made that day lived in exactly one place. My head.
"Every decision has a human owner" is a good rule. But it begs a harder question: Who owns the context that the human needs to make the ultimate decision?
In most startups the answer is "the founder, in their head, until it rots." That's fine at 5 people. It's catastrophic at 25. And it's genuinely terrifying when the 25 also includes dozens of agents who will happily make a confident, well-reasoned, completely wrong decision the moment your attention drifts.
In his book “An Elegant Puzzle, Systems of Engineering Management”
lays out the best ways for information to aggregate and flow through engineering teams to reach quick and actionable consensus:
The tried and true pattern is a senior lead who sees every PR and sets the patterns everyone else executes against, and this pattern works because of that managerial presence. The lead isn't catching mistakes; they're loading the context before the mistakes can happen.
A founder can't be in every room. But a graph can.
Engram v4.0: Business Superintelligence
v4 of Engram isn't a conceptual shift. It's the evolution and realization of the original idea, the one that started this whole project:
What if everything was ingested as context?
- Every client meeting.
- Every investor call.
- Every Slack thread.
- Every voice note on a walk.
- Every decision.
- Every relationship.
- Every deal.
v3 proved the memory graph could work for code. v4 is what happens when you stop drawing a line around code and let the graph hold the whole business.
Heres what changed.
1. The "Curator": an always-on service that thinks about the business while nobody's watching
This is the piece that actually earns the word "superintelligence," and it's the one I'm most excited about.
In v3, Curator was a maintenance routine. It ran inside an agent session, tidied up the vault, consolidated the mycelial algorithms, and then went away. Useful, but passive. You had to be the one to start it, and when you closed the session it stopped existing.
In v4, Curator is its own service. It runs in Docker with its own schedule, its own lifecycle, and its own job. And that job isn't maintenance- it’s to think about the business while nobody's watching. It runs on three tiers:
Tier 1 ( every 5 minutes ) A filesystem loop notices anything new in the vault inbox, classifies it, and for high-trust sources promotes it straight into the graph without waiting for a scheduled sweep. A meeting transcript that lands at 10:03 is part of the graph by 10:08.
Tier 2 ( every hour ) Twelve steps: inbox processing, mycelial consolidation, entity extraction, vault-to-graph sync, wikilink weaving, relationship inference, staleness scanning, conflict resolution, schema enforcement, cross-reference intelligence, deal tracking and opportunity scoring, index regeneration and health reporting. Every hour the graph gets reorganized, re-weighted, and re-scored against everything that happened since the last sweep.
Tier 3 ( daily at 6am, with weekly and monthly variants ) This is where Curator looks at everything that changed in the last 24 hours, compares it against the weeks and months before it, notices the connections a founder would miss, and writes a strategic briefing that lands in the vault before I wake up.
The cross-reference intelligence step is the one worth pausing on. It's a pattern detector that walks the graph looking for things a founder couldn't reasonably notice on their own. A few of the patterns it finds:
- Shared portfolio. Two prospective clients turn out to be portfolio companies of the same investor. The graph noticed the edges line up.
- Warm intro paths. I want to reach someone at a fund in Madrid. The Curator finds that Niko went to business school with someone who used to work there, who still talks to the person I'm trying to reach, and writes the two-hop path into the briefing.
- Resonating topic. Five investors asked about compliance this quarter. Individually, none of those conversations felt like a pattern. Collectively, they're a signal about what the market is actually worried about right now, and Curator is the only thing holding all five of them at once.
- Converging signal. Three meetings this month mentioned Australian stablecoin settlement without anyone coordinating. That's a theme showing up in the graph before it shows up in my head. It makes a note to reach out to
@KevLeht
and
@borderlessxyz
to preemptively solve this. - Stale relationship. I haven't talked to someone in 90 days. The graph also knows that person is connected to a goal that's currently active. It flags the gap before it costs me the relationship.
And these are just the patterns Curator already knows to look for. The list isn't fixed. Twice a week, Curator runs its own research session against the graph, asking a different kind of question: what patterns exist in this data that I'm not currently looking for? It walks the graph cold, tries new cross-sections across entity types and time windows, evaluates whatever it finds against a qualification bar (does this correspond to something a human would actually want to know?), and presents the surviving candidates to leadership as proposed new pattern types. If we greenlight one, it gets promoted into the live detection set and runs alongside the others on the next sweep.
Curator is learning what kinds of patterns are worth finding, and the library of things it watches for gets longer every week without anyone writing a new rule.
2. The thinking layer: Obsidian paired with Neo4j
The Obsidian vault is still the source of truth. Human-readable, git-friendly, wikilinks as edges. It's where humans and agents read, write, and edit. Nothing about v4 changes that, and it isn't going anywhere.
Once we started modeling organizations, deals, people, meetings, and strategic threads as proper entities with proper relationships, markdown-as-graph stopped scaling as a query surface. Walking files to answer a question across 200 notes is fine. Walking files to answer a question across 20,000 notes, hourly, with cross-temporal pattern detection running on top, is not.
So v4 pairs the vault with a Neo4j graph database. The vault is the write side, Neo4j is the read side. The Curator's sync step parses every note, classifies it, and upserts it as typed nodes and edges. The mycelium algorithms (spreading activation, temporal decay, path reinforcement, flow scoring) now run as graph operations instead of file walks. Humans live in the vault. The Curator and the query layer live in the graph. Both stay in sync because keeping them in sync is one of the Curator's twelve steps.
The practical upshot is that you can now ask the graph real questions. Not "find me notes that mention Acme Corp," that's just search. I mean things like "show me every deal where the decision-maker went quiet for more than 10 days after a pricing conversation" and get an answer that's actually grounded. Importantly, you can have the Curator ask that question itself, on a schedule, without anyone prompting it. It is automated custom work that as
says: removes the manual cost from attempting to do it.
Where Judgment Lives
AI isn’t dangerous, but judgment and action without context is the actual failure mode and context is the thing AI doesn't have by default.
The rule a lot of teams are converging on: AI assists, humans own.
Humans own the judgment, the graph owns the context, and AI executes across both. Remove any of the three and the output collapses. Keep all three and you get what we're starting to see internally: we individually bring the full institutional memory of our company into every room we walk into, and every room we can't walk into is covered by an agent with the same memory. It’s not about just being faster founders; we now have coverage we’ve never had before.
But I should be forthright about why we're putting this much work into Engram, because it isn't charity and it isn't a side project.
The Curator is a prototype: Not of a memory system, but of our product philosophy.
Everything I described above is the Curator pointed inward, at our own business. It watches our meetings, our deals, our relationships, our roadmap. It finds patterns we wouldn't notice. It surfaces things before we think to ask. Now point the same loop outward, at a customer's data, and you get a different kind of product entirely.
The Future Lies in Personalized, Intelligent, Generative Software
is a payments-first self-custodial neobank built on stablecoin-based payment rails, giving traditional merchants immense control over their financial infrastructure. Our customers generate an enormous amount of signal just by operating: transaction flows, settlement timing, failure patterns, sales behavior, days-payable / days-receivable ratios, cross-border money movement, payment types, feature requests… Today, every SaaS tool in that stack (including most of ours) waits to be asked before initiating. A customer notices a problem, files a ticket, requests a feature, or churns quietly. The software is reactive by design.
Our production backend is designed to run the same loop that Curator runs, but with an opt-in system pointed at each customer's individual data. Curator is being designed to ingest all customer data, actions, and intents, and then find patterns. It will notice the converging signal, the stale flow, the emerging themes in how a merchant is using Easy. And then, instead of waiting for the customer to describe a problem they haven't fully formed yet, it will surface the pattern and propose a personalized fix. Sometimes that's a configuration change, sometimes it's a new report, or it's a feature we haven't shipped yet and the system will either build the generative UI for that feature or request developer attention to ship it.
A self-evolving product. Not in the hand-wavey "AI will fix it" sense, but in the specific sense that the loop we're already running internally is the same loop we want running for every customer on the platform.
That's
's rule but one layer higher. The Curator surfaces the pattern. A human at Easy decides whether it's the right thing to build. The customer never has to know the pattern exists, because by the time they'd have thought to ask for the solution, it's already shipped.
Engram is the distilled version of what we run internally. The memory substrate, the pattern engine, the curator loop, the graph-native reasoning. It's the foundation, and it's the basis for the system we're building for our individual merchants. It isn't the whole stack. Sorry guys but Easy’s full product (the payments-specific pattern library, the production pipelines, the cohort-learning layer, the tooling that only makes sense inside a regulated financial environment) stays behind the curtain. We're sharing the engine; we're not shipping the car.
We want other people to build on it and find complementary patterns we didn't think to look for, and share those findings. If you can substantially improve the way we’re thinking about this: we’re hiring. We're keeping what sits on top: the payments and financial operations suite.
Most SaaS companies compete on features… We'd rather compete on whether the software is paying attention.
---
Engram is MIT licensed. v4 is in active development and we'll cut it as the next stable release once Meeting Copilot ships. If you're building agentic products and you've felt the session-amnesia pain, v3 will help you today. If you're starting to feel the founder-amnesia pain (the one where the business is moving faster than any single human can hold in their head), v4 is being built for exactly that. And if you're thinking about what software looks like when it stops waiting to be asked, we're building toward that in the open.
- Repo:
https://github.com/itseasyco/engram
- Package:
- Easy Labs:
AI assists. Humans own. The graph remembers. And the best software is the kind that notices first.