Here is the job that needed solving. I run a set of agents across my own business and client accounts. One writes ad creative from customer reviews. One rebuilds the weekly reporting deck. One drafts and deploys Klaviyo flows. Individually they were useful. Collectively they were exhausting, because every one of them woke up with no idea what the others had done, and no idea what I had already ruled out.
The creative agent would propose an angle we had tested and killed in July. The reporting agent would flag a metric drop that had a known cause I had explained to a different agent a fortnight earlier. Every run started at zero. I was the memory, and being the memory is a full time job that scales with the number of agents you run.
What fixed it was giving them somewhere to write things down that I could also read. That place is a set of Notion databases, connected through the Notion API. Not because Notion is the best database in the world, because it is not, but because it is the only one where the agent and the human are looking at the same record without anyone exporting anything.
What an agent with no memory actually costs
The obvious cost is repetition. You re-brief. You re-explain the offer, the voice, the seasonality, the fact that the founder hates the word premium. Twenty minutes a day, five days a week, across four agents, and you have handed back most of the time the automation was supposed to save you.
The real cost is worse than repetition. It is contradiction. Two agents working the same account with no shared record will make opposing decisions and both look confident doing it. One writes a win-back campaign around a discount. Another has already logged that discounting is off the table this quarter for margin reasons. Nobody catches it, because there is nowhere for the catch to happen. This is the same failure mode as tool sprawl, where DTC brands now spend around 40 percent of retention budget on software and still have nobody holding the strategy. More systems, less coherence.
An agent without memory is a tool. An agent that reads the same record you do, and writes back to it, starts behaving like a colleague. The difference is not model quality. It is whether there is a shared place to put things.
The workflow we actually run
Every brand we work with gets the same four databases in one Notion space, and every agent is given a scoped token to exactly the ones it needs. Nothing is workspace-wide. The creative agent cannot see the financial reconciliation records, and it does not need to.
Database 1
Brand context database
One row per brand. Voice rules, banned words, offer architecture, margin floors, the customer language pulled out of reviews, and the things the founder has explicitly ruled out. Roughly 900 words. Every agent reads this row before it does anything. This one database killed most of the daily re-briefing on its own.
Database 2
Decision log
Every meaningful call, dated, with a one line reason. Tested and killed, paused for margin, deferred to Q4. Agents query it by status and date before proposing anything, which is what stops the creative agent resurrecting an angle we buried two months ago.
Database 3
Campaign and task tracker
Live work in flight. Agents create rows when they start something and update status when they finish, so the tracker is the handoff point between agents and between me and them. I open it in the morning and see what ran overnight without reading a single log file.
Database 4
Output archive
Finished deliverables written back as pages: the reporting deck summary, the ad concepts, the flow definitions. The point is not storage, it is that the next agent can read what the last one shipped rather than guessing.
The read pattern matters as much as the schema. An agent does not pull the whole workspace. It queries one database with a property filter, takes the rows it needs, and stops. Reads are cached for the length of a run so the same context is never fetched twice. On a normal morning run that is somewhere between six and fifteen API calls, not six hundred.
The write pattern is deliberately dumber. Agents append rows and update status properties. They do not restructure databases, delete rows, or edit the brand context row. Anything that changes the shape of the memory is a human decision, because an agent that can rewrite its own instructions will eventually do exactly that.
Where the Notion API is genuinely bad
It is slow, and it is slow structurally rather than by accident. Page content lives in nested blocks, so reading a full page means recursive calls to fetch children, and every level paginates on its own. The rate limit sits at an average of three requests per second per integration. Paginate a 5,000 row database at 100 rows a page and that is 50 requests before you have read a single word of content. Pull the full block content of every row and you have added 5,000 more, which is roughly 28 minutes of waiting. Design a workflow that reads everything and it will fall over.
Search is the second weakness. There is no serious full text search across content, so you filter on database properties instead. That means the schema has to carry the meaning. If your decision log has a free text notes field and nothing else, an agent cannot find anything in it. Statuses, dates, and tags do the work that search would do elsewhere, which is more upfront design than people expect.
And pagination cursors expire. If a long pull pauses for a rate limit backoff, the cursor you were holding can go stale mid-loop. Any pull that runs for more than a couple of minutes needs to be resumable and idempotent, or you will silently lose half a dataset and not notice until the output looks thin. We keep anything high volume in a proper database and sync a readable view into Notion. Notion is the shared surface, not the source of truth.
What this looks like in practice
The visible change is small and boring. I open one page in the morning and the overnight work is there, with status, output, and what each agent decided. No log files, no chasing, no re-briefing. The invisible change is the one that matters. The agents stop contradicting each other, because they are all reading the same decision log before they act.
It also changes what a handover looks like. When a brand asks why a campaign was structured the way it was, the answer is a dated row with a reason attached, not somebody trying to remember a conversation from six weeks ago. That record is useful long after any particular agent has been replaced.
None of this makes an agent smarter. It makes it consistent, and consistency is what turns a clever demo into something you can actually run a business on.
Inside the system
How we build this for brands
The memory layer is the first thing we set up, before any agent is pointed at an account. The brand context row gets written from real material rather than a questionnaire: the VOC engine mines customer reviews and support messages into the language buyers actually use, and that language is what the ad creative and the Klaviyo flows are then built from. It is why the email and the Meta ad someone sees in the same week finally sound like one brand.
From there the reporting agent writes weekly findings back into the same space against live Shopify and ad data, so leakage and risk land in the tracker rather than in an inbox nobody reads. Part of this runs live for portfolio brands today; the full system is what we deploy when we take a brand on.
Operations Audit
Find out how much of your week is spent being the memory
I will map where your brand context actually lives right now, who has to hold it in their head, and what it is costing you in repeated work and contradictory decisions. You get the map and a plan for what to move into a shared layer first.
Book Your Operations AuditFrequently asked questions
Why do AI agents need a memory layer?
Because a model starts every run with no recollection of the last one. Without an external store it will re-suggest a campaign you rejected in March, re-test an offer that already failed, and re-ask for the brand voice you defined six weeks ago. A memory layer is a database the agent reads before it acts and writes to after it acts, so decisions accumulate rather than reset.
Can the Notion API be used to give AI agents access to a workspace?
Yes. The Notion API exposes databases, pages, and blocks through a token-scoped integration, so an agent can query a database with filters, read page content, create rows, and append blocks. Access is granted per page or per database rather than workspace-wide, which is what makes it safe to give an agent write access to a campaign tracker without exposing the rest of the workspace.
What are the Notion API rate limits?
An average of three requests per second per integration, with short bursts above that, plus per-workspace limits that scale with the plan. Because content is nested, reading a full page means recursive calls to fetch child blocks, and every pagination cursor counts as a request. Paginating a 5,000 row database at 100 rows per page takes 50 requests, and pulling full block content for every row adds 5,000 more, roughly 28 minutes at the ceiling.
Is Notion a good database for automation?
It is a good shared surface and a poor transactional database. Use it where a human needs to read, edit, and trust the same records the agent works from: campaign trackers, decision logs, brand context. Do not use it for high-volume writes, real-time state, or anything where a lost write matters. Put a real database underneath for that and sync a readable view into Notion.
What does the Notion API do badly?
Three things. Reads are slow because block content is nested and every level paginates independently. Search is weak, so you filter database properties rather than searching content, which means the schema has to carry the meaning. And pagination cursors can expire if a loop pauses for a backoff, so long pulls need to be resumable rather than assumed to run clean.
How long does it take to set up a memory layer for a brand?
The database structure takes an afternoon. Writing the brand context row properly takes longer, because it should come from real customer language and real decisions rather than a questionnaire. In practice we get a usable version live in a week and it keeps improving, because every decision logged after that makes the next agent run better than the last.
About the author
Caner Veli built Liquiproof to global distribution across 3,000+ retailers, then exited. He now runs Purposeful Profits using a combination of operator strategy and AI-powered systems he has built and uses daily, having 10x'd monthly revenue in his own business in the last 90 days.