Sovereign Agentic AI (Volodymyrs View) Podcast

About Sovereign Agentic AI (Volodymyrs View) Podcast

Sovereign Agentic AI . How to make AI personal and make a proper memory and Knowledge representation . How to make agents that do what you ask for volodymyrpavlyshyn.substack.com (https://volodymyrpavlyshyn.substack.com?utm_medium=podcast)

Publisher

Volodymyr Pavlyshyn

Category

society & culture · technology

Language

en

Explicit

No

First episode

18 Feb 2026

Latest episode

3 Jun 2026

Latest episodes

13 episodes in the feed.

1. 

   3 Jun 2026

   Beyond the Context Graph: Why Organizations Need World Models, Not Another Graph

   Agents are booming. They are everywhere, and every business wants them. But businesses hit the wall faster than individuals do — they run into hallucinations and unverifiable decisions almost immediately, because in a company a wrong decision has a cost, an owner, and a paper trail. An individual playing with an agent can shrug off a bad answer. An organization cannot. So the real question is not “which agent framework do we use?” It is “how do we change the shape of the organization so it is actually ready for agents?” How do we modernize the structure so that this massive extension of humans by machines is safe, auditable, and worth the risk? Context graphs are knowledge graphs wearing a new hat Every week there is something new. First it was the great context-graph boom — track every decision, wire up every interaction, build the One Graph. There are countless frameworks and countless talks on how to build a context graph. I’ll say the quiet part out loud: a context graph is mostly a good old knowledge graph with fresh branding. That isn’t an insult — knowledge graphs are powerful — but the rebrand hides what’s missing. To make any of this work in an organization you need memory, you need shared context management, and you need audits, promises, and decision traces. A graph alone gives you structure. It does not give you the discipline of knowing who promised what, on what basis, and whether it held. This is the argument I develop at length in my in-progress book, Beyond Context Graphs: Agentic Memory, Cognitive Processes, and Promise Graphs (https://leanpub.com/beyondcontextgraphs). It’s still growing — I’ll be honest, I have promised myself to push it well past where it sits today — but the spine of the idea is already there. You don’t need one solution. You need many. Here is the structural mistake almost everyone is making. In a real organization you have many people, each with a different context, each specialized. You would never hire one person to act as CFO, CTO, and CRO simultaneously and then, in their spare time, single-handedly write the corporate ERP system. That would be absurd. Yet that is exactly what we are trying to do with AI. We are cramming everything we have into one head — one model, one prompt, one context window — with no proper split of role, context, and memory. We took an organization that survives precisely because it distributes cognition across many specialized minds, and we tried to collapse it back into a single brain. Of course it hallucinates. Of course its decisions can’t be verified. We removed every boundary that made the original system accountable. The answer comes from robotics: world models The way out arrived from a field that has been thinking about embodied agents for decades — robotics. The idea is the world model, and it deserves a book of its own, which is why I wrote World Models for AI Agents (https://leanpub.com/agenticworldmodels). A world model describes the environment around the agent — the place where it actually operates. It encodes the rules: what is possible, what is feasible, and what is forbidden at any price. Things like: do not share sensitive company data with the lovely, unverified agents that connect to you and send you requests. The agent doesn’t merely retrieve facts; it understands the terrain it is standing on and the lines it must not cross. So what lies beyond the context graph is not exotic. It is almost old-fashioned: * A genuinely shared context across the organization. * Causality analysis — event tracking, and understanding how business events influence one another. * A real analysis of the supply chain. * A real analysis of the company’s business processes — do they even exist? How do they actually run? Who influences them? We are circling back to a more boring reality. To make agents work, we have to document and understand how we operate, find the seams where agents can plug in, and hand them the context to do real work. The unglamorous prerequisite to magic is knowing how your own company functions. Institutional memory plus a network of specialized world models Organizations need institutional memory. But more than that, they need a set of specialized world models. One world model for finance. Another for operational support. Each tuned to its domain — and all of them sharing a common knowledge base of facts about the company. Maybe even facts about competitors and the state of the market. Together these form a network of knowledge with its own internal roles: * Librarian agents that curate and serve the knowledge. * Guard agents that enforce who is allowed to see what, so sensitive data is never exposed to the wrong requester. I’m convinced that institutional world models, sitting alongside knowledge graphs, will become the most important asset any business can own — including businesses that make physical goods. The factory still matters. But the model of how the factory thinks becomes the crown jewel. The boring part is the safety part If you want to extend an organization into a true hybrid of human and artificial intelligence, you need a detailed and controlled environment. Not vibes — controls: * Policies that define acceptable action. * Guardrails and hardening that hold under pressure and adversarial input. * Data access controls that decide who and what sees each fact. This is the unsexy infrastructure that turns “we deployed some agents” into “we run an agentic organization.” Digital avatars and the swarm There’s a more human-facing piece too. If we want an agentic organization, we’ll want some kind of digital avatar of ourselves — a delegate that can contribute to the swarm. We externalize a slice of our own thinking so the agents can keep communicating, deciding, and working while we sleep, eat, and actually enjoy our lives. The point is not to be always-on. It’s to no longer have to be. Break the silos — but keep the humans Which brings me to the part everyone secretly recognizes. Every organization has a Dave — the one person in some department who alone knows how the corporate magic works. And every organization has a Steven: the oldest engineer, who arrived as an intern, watched everyone else change roles or leave, and now carries twenty years of “why we built this crap” entirely in his head. Sometimes Steven is too honest. Sometimes he’s sarcastic and hard to work with. And sometimes he is the single point of failure for the entire company. I am not saying replace Dave and Steven. Let me be clear about that. I’m saying break the silos — get the knowledge out of human heads and make it available to agents, so the company no longer depends on whether Steven is in a good mood, or still employed. One of the core tasks, then, is to build the foundational world model that explains the environment and the rules to the agents. Then build a causal inference engine on top of that data, so the decisions of humans and agents become explainable at scale. This last point is not optional: if you want secure AI, you need explainable AI. You cannot guard what you cannot account for. Where to start So that’s the thesis. We desperately need something beyond context graphs — and that something is world models and agentic memory. If we want to integrate agents and grow into hybrid human–machine organizations, the prerequisites are unglamorous: documented processes, shared institutional memory, specialized world models, librarian and guard agents, hard policies, and a causal layer that makes the whole thing explainable. If you want to go deeper, both books carry this forward: * Beyond Context Graphs: Agentic Memory, Cognitive Processes, and Promise Graphs (https://leanpub.com/beyondcontextgraphs) * World Models for AI Agents (https://leanpub.com/agenticworldmodels) And the rest of my work on agentic memory, knowledge graphs, and edge AI lives here: leanpub.com/u/vpavlyshyn (https://leanpub.com/u/vpavlyshyn). Stay connected, and never stop discovering. In the meantime, ask yourself the question that actually matters: what does your institutional memory and world model look like? What layers does it have? And what knowledge is so fundamental that every agent in your company should understand it before doing anything at all? Get full access to Sovereign Agentic AI (Volodymyrs View) at volodymyrpavlyshyn.substack.com/subscribe (https://volodymyrpavlyshyn.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

2. 

   27 May 2026

   The AI Cohesion Paradox: Why AI-Empowered Teams Cooperate Less — And What Leaders Can Do About It

   The AI Cohesion Paradox Why AI-Empowered Teams Cooperate Less — And What Leaders Can Do About It Volodymyr Pavlyshyn | Sovereign Agentic AI “The human is not the island.” We repeated that for decades. It turns out we were wrong — or at least, AI is proving we can be. Something quietly changed in the organizations that moved earliest and fastest on AI. Their people got faster, their output went up, their sprint velocity looked great — and then the seams started to show. Departments that had once collaborated spontaneously began operating like sovereign states. Engineers who used to grab a coffee and talk through a design decision now just... asked their agents. The common context that used to live in a team’s informal exchanges — the “have you talked to Dave about this?” moments — started evaporating. This article is about that phenomenon. It draws on a wave of recent empirical research (2023–2026) from the Journal of Applied Psychology, Harvard Business School, Deloitte, Microsoft Research, and KPMG, as well as on direct practitioner observation of what happens when hybrid human-agent teams try — and struggle — to coordinate. The thesis is simple: AI adoption, left unmanaged, reproduces the worst features of the old departmental silo era at a new and deeper level of isolation. Solving it requires a deliberate discipline that barely has a name yet: social architecture for AI-empowered organizations. 1. The Productivity Mirage Start with what makes this paradox so hard to see. The headline numbers are real. Brynjolfsson, Li & Raymond’s landmark NBER study of 5,179 customer-support agents found a 14% average productivity gain from AI access, with novice workers improving by 34%. The Harvard/P&G “Cybernetic Teammate” field experiment (Dell’Acqua, Sadun, Lakhani et al., NBER WP 33641, 2025) showed that individuals working with AI matched the output quality of two-person teams without it. So the efficiency case is solid. The problem is that efficiency is measured per-person, per-task, per-sprint. Social cohesion is measured across people, over time, through the informal tissue of an organization. And that tissue is what is being quietly consumed. 65% of US knowledge workers now default to a chatbot before asking a colleague. The habit that built informal networks — the act of asking — is disappearing. — MOO / Censuswide Survey, May 2025 (N=1,000) The MOO/Censuswide survey (May 2025, N=1,000 US knowledge workers) found that 84% of employees actively encouraged to use AI at work reported increased feelings of loneliness — and 65% admitted what researchers called “cognitive outsourcing”: defaulting to a chatbot before asking a human colleague. That habit of asking is not just efficient. It is the mechanism by which weak ties form, by which informal knowledge moves across departments, by which people learn that a colleague has expertise worth consulting. When you stop asking Dave — even because you now have a faster answer — Dave’s expertise also stops flowing through the organization. And the next time you need to integrate with Dave’s domain, you discover you have no mental model of it at all. 2. The Research Evidence: What Is Actually Happening Loneliness, Sleep Loss, and the “Asocial System” The most rigorous causal evidence comes from Pok Man Tang and colleagues (Journal of Applied Psychology, June 2023), who ran four studies across Taiwan, Indonesia, Malaysia, and the US (N=794). The finding: the more employees interacted with AI systems, the more they reported loneliness, insomnia, and after-work alcohol consumption. Tang’s framing is precise — AI is creating what he calls an “asocial system, wherein people may feel socially disconnected at work.” This is not about AI being bad. It is about AI removing the social friction that was, paradoxically, serving a function. Collaboration Networks Are Fragmenting Microsoft Research’s Yang et al. (Nature Human Behaviour, 2021, 61,182 employees) documented that digital-first work caused collaboration networks to become “more static and siloed, with fewer bridges between disparate parts,” with cross-group collaboration time dropping roughly 25%. That study was triggered by the pandemic. The pattern it captured — reduced bridging, hardened clusters — is now being amplified by AI, because AI removes the prompts that used to drive cross-cluster contact. The KPMG / University of Melbourne global trust study (2025, ~48,000 respondents across 47 countries, led by Nicole Gillespie and Steve Lockey) surfaces the most alarming single statistic: 50% of employees now report that they use AI instead of collaborating with colleagues. The same study found 61% hide their AI use from managers and 55% pass AI-generated work off as their own — a trust erosion problem layered on top of the collaboration problem. “Workslop” and the Interpersonal Trust Tax BetterUp Labs and Stanford’s Social Media Lab published a striking HBR piece in September 2025 (N=1,150 US desk workers) introducing the concept of “workslop” — AI-generated output that is detectable and shifts cognitive effort to the receiver. The finding: 54% of respondents rated a colleague who sent them obvious AI output as less creative, capable, and reliable; 42% rated them as less trustworthy; and roughly 30% said they would be less likely to want to work with that person again. The authors’ verdict: “The most alarming cost may be interpersonal.” 42% of workers rated a colleague who sent AI-generated “workslop” as less trustworthy. Productivity tools are simultaneously becoming trust liabilities. — BetterUp / Stanford / HBR, 2025 “Cultural Debt” — Deloitte’s Framework for Leaders Deloitte’s 2026 Global Human Capital Trends report introduced the concept of “cultural debt” — the cost that accumulates when people work less with one another because they are working more with AI. The numbers are striking: 80% of leaders, managers, and workers worry their colleagues are using AI to appear more productive than they are; 65% believe their culture needs significant change because of AI; but only 5% report great progress. Just 6% of organizations are actively redesigning work for human-AI convergence. Only 40% of leaders design AI for both business and human outcomes; 56% design for business outcomes alone. Marcia Oglan, SVP of Enterprise HR at Highmark Health, put it directly: “Tech won’t solve trust issues. Only visible, consistent leadership and accountability can do that.” 3. The Mechanism: Why This Happens in AI-Heavy Teams Substitution at the Dyad Level When the marginal cost of “asking” drops to zero — because the AI always has an answer, never has a bad day, and never makes you feel stupid — people stop walking over to colleagues. This is natural, rational, and socially catastrophic at scale. The social network theorist Mark Granovetter identified decades ago that “weak ties” — infrequent, cross-cluster connections — are the conduit through which novel information and opportunities flow in organizations. AI is systematically eliminating the prompts that formed those ties. Put simply: you ask your agent. Your agent doesn’t talk to Dave’s agent. Dave’s domain knowledge stays with Dave’s agent. And you lose the ability to integrate. The Railway Problem: Integration Without Communication There is an old paradox from the early railway era — two track-laying crews, building from opposite ends of the continent, whose rails did not match when they met in the middle. Integration depends on communication, and communication depends on a social substrate that shared context makes possible. In AI-heavy teams, this problem is returning in a new form. Different team members use different agents, different prompts, different mental frameworks — even when nominally following the same spec-driven methodology. The agents rewrite codebases in ways that make integration almost impossible. Guardrails help. Architectural decoupling helps. But they also increase the total volume of generated code, because you have to explicitly over-specify boundaries that used to be maintained by people talking to each other. The Loss of Internal Critics There is a subtler problem: AI does not judge. It does not push back. It does not tell you that your design is wrong, that your framing is confused, that you are solving the wrong problem. For introverted engineers especially, this is seductive — the agent is always supportive, always constructive, never territorial. But teams need friction. They need the capability for peer review that assumes the reviewer actually cares about the work and has skin in the game. When the primary interlocutor becomes an agent, that critical capacity weakens. What Deloitte calls “cultural debt” and what the MIT Media Lab (2025) calls “cognitive debt” are two sides of the same coin: we are offloading both thinking and social judgment simultaneously. AI doesn’t judge. AI doesn’t fire back. AI doesn’t criticize you. And that’s exactly the problem. We are losing the internal critics in our teams — and with them, the ability to do real peer review. The Multi-Agent Coordination Gap The deepest structural problem is that we have not yet learned how to orchestrate agents across teams. Each engineer has their own agentic cluster — their own prompts, their own context, their own reasoning style. Even with shared specifications and common project memory, the agents of two team members can produce code that is incompatible at the integration boundary. We have some tools for context management (shared CLAUDE.md, OpenSpec, shared knowledge bases), but they solve the intra-person context problem, not the inter-agent integration problem. The question that remains open: if humans are not interacting with each other, can their agents interact with each other? The honest answer in 2025–2026 is: not yet, not reliably, not at the scale that matters for real team coordination. 4. The Counter-Evidence: When AI Breaks Down Silos The picture is not uniformly bleak. The Harvard/P&G “Cybernetic Teammate” experiment (Dell’Acqua et al., 2025) produced a striking counter-result. Without AI, R&D professionals produced technical solutions and commercial professionals produced commercial ones — a classic expertise silo, measurable as bimodal output distribution. With AI, both groups produced balanced cross-functional solutions. The AI acted as a bridge between expertise domains that organizational structure had separated. But notice the conditions: this happened in a deliberately designed one-day workshop with explicit cross-functional pairing. The AI did not break down silos autonomously — it broke them down because the social architecture was set up to make that possible. Dell’Acqua’s observation deserves to be heard carefully: “If these expertise silos can have a very different shape with AI, we may want to rethink the design of organizations.” Oracle’s Rob Pinkerton is precise about the mechanism: “AI agents do not create silos on their own, they magnify the structure that already exists.” Both findings point to the same conclusion. AI is an amplifier. What it amplifies is the organizational design you bring to it. 5. Social Architecture: A Design Discipline for AI Organizations “Social architecture” is not a new term, but it has a new urgency. In the context of AI-empowered organizations, it means the deliberate design of the norms, rituals, structures, and infrastructure through which humans — and their agents — maintain common context, shared understanding, and productive integration. The key insight is that social architecture is not what happens after you deploy AI. It is what you design before you deploy AI, and what you actively maintain during. Treating it as residue — as what is left over after the AI tools are chosen — is precisely how cultural debt accumulates. The Autonomy-Coherence Tradeoff There is a genuine design tension at the heart of multi-agent team architecture. On one extreme: give all agents a shared brain, a common context, full alignment. Coherence is high; autonomy is low. On the other extreme: fully independent agents with zero shared state. Autonomy is high; integration is a nightmare. Most teams are discovering, through painful experience, that the answer is a hybrid — shared context at the specification and goal level, independence at the execution level — with explicit integration protocols that substitute for the communication that used to happen informally. The speed of execution has outpaced the speed of integration. Agents can build faster than teams can align. The gap between building velocity and integration capacity is where projects go wrong. What Social Architecture Actually Requires Effective social architecture in 2025–2026 requires attention to at least four layers: * Common context infrastructure — shared specification documents, project memory systems, agreed ontologies for what the work is and what “done” means. This is not merely technical; it requires the humans to agree before the agents can be aligned. * Human interaction rituals — deliberate, protected time for human-to-human exchange that is not mediated by AI. Not because AI is bad, but because the informal channels it replaces were doing work that no one measured. * Integration protocols — explicit agreements about how agent-produced work will be merged, reviewed, and reconciled. Code review processes designed for AI-generated code, not just human-generated code. * Trust norms around AI disclosure — clear, psychologically safe agreements about when and how AI use is visible. The KPMG data shows 61% of employees hide their AI use; that hiding is itself a signal of social fracture. The solopreneur who does everything himself may not feel this problem at all. But he is creating it for his future self — the one who eventually needs to work with other people, or whose agents need to work with other agents. 6. What Leaders Can Do In the next 90 days: diagnose before you deploy further Run an Organizational Network Analysis (ONA) baseline now, before the next wave of AI tooling lands. If you cannot see your current cross-functional tie density, you cannot see it eroding. Microsoft Workplace Analytics and similar tools make this tractable at enterprise scale. Add three questions to your next engagement pulse: * How often in the last week did you ask AI a question you would previously have asked a colleague? * Do you feel comfortable telling your manager you used AI on a task? * Has a colleague’s recent work felt obviously AI-generated? Track these over time. The trend line matters more than the absolute numbers. In the next 6–12 months: design for human connection, not just productivity Adopt what Deloitte calls “human moments” as policy — at least one meaningful human-to-human interaction per major workflow. This sounds obvious. It is not happening. Only 6% of organizations are actively redesigning work for human-AI convergence. Atlassian’s redesign of AI onboarding (per Zachary Parris, former Director of Organizational Effectiveness) is instructive: by pairing AI adoption with deliberate transparency, safeguards, and trust-building rituals, they lifted average weekly AI usage among new hires from 57% to 93%. The lesson is not about usage rates — it is that social scaffolding and AI adoption reinforce each other when designed together. Slack’s Fall 2024 Workforce Index (N=17,372 desk workers) found that workers comfortable sharing their AI use with their manager are 67% more likely to have used AI for work than those who would not be comfortable disclosing it. Disclosure norms matter as much as the tools themselves. In the next 1–2 years: build the governance infrastructure IBM’s experience is instructive and sobering. Their AskHR AI system now handles roughly 11.5 million employee transactions annually with 94% of questions answered entirely within the system. But when IBM first forced a comparable rollout in 2018, employee HR Net Promoter Score dropped from +19 to −35. Recovery took years of iterative redesign. The lesson per CHRO Nickle LaMoreaux: “AI is not magic. It takes hard work, behavior change, culture change, business process change, and sometimes leadership change.” 7. The Deeper Challenge The old axiom — “no person is an island” — assumed that human social need was a structural guarantee of cooperation. It was not a policy; it was physics. People cooperated because they had to, because the cost of not cooperating was isolation and the friction of isolation was intolerable. AI changes the physics. You can now be a highly functional, highly productive island. You can have a team of agents who never push back, never have a bad day, never disagree with your framing. You can even, at small scale, build genuinely great products this way — the rise of solo founders and two-person AI-native companies is real evidence of this. But the scale problem is not solved. When you grow — when you need to coordinate with other islands, when your agents need to work with someone else’s agents, when the integration challenge becomes the bottleneck — the social architecture you did not build becomes the crisis you cannot avoid. The cognitive and social capacity that allows teams to integrate — to build the shared mental models, to navigate the trust relationships, to maintain the common context that makes coordination possible — is exactly the capacity that is quietly atrophying in organizations that lean hardest on AI without designing for human connection. We have thousands of years of experience in human-to-human interaction, and we still fail at it regularly. We have almost no experience in agent-to-agent interaction, or human-to-agent-to-human interaction. We are designing the social architecture of the future while flying, and most organizations don’t even know they’re flying. The research is clear enough: this is happening, the effects are measurable, and the organizations that design for it now will have a structural advantage over those that discover it as a crisis. The harder problem is that the discipline of human connection has never had to be explicit before, because it was automatic. Making it explicit, without destroying the authenticity that makes it valuable, is the leadership challenge of the AI transition. Key Concepts * Asocial system (Tang et al., 2023) — a workplace in which AI displaces the social feedback loop that used to sustain informal coordination. * Cultural debt (Deloitte, 2026) — the accumulating organizational cost of neglecting culture and human connection during AI rollout. * Cognitive debt (MIT Media Lab, 2025) — degraded human analytical capacity from over-reliance on AI cognitive offloading. * Workslop (BetterUp / Stanford / HBR, 2025) — detectable AI-generated output that shifts cognitive burden to the receiver and damages interpersonal trust. * Cybernetic teammate (Dell’Acqua et al., 2025) — a frame for AI as a cross-functional bridge, achievable when social architecture is designed to support it. * Social architecture — the deliberate design of norms, rituals, and infrastructure through which humans and their agents maintain common context and productive integration. Selected Sources Empirical research * Tang, P.M. et al. (2023). “No Person Is an Island.” Journal of Applied Psychology. Four studies, N=794. * Yang, L. et al. (2021). “The effects of remote work on collaboration among information workers.” Nature Human Behaviour. N=61,182 Microsoft employees. * Dell’Acqua, F., Sadun, R., Lakhani, K. et al. (2025). “The Cybernetic Teammate.” NBER Working Paper 33641. Field experiment, N=776 P&G professionals. * Brynjolfsson, E., Li, D., Raymond, L. (2023). “Generative AI at Work.” NBER Working Paper 31161. N=5,179 agents. * BetterUp Labs / Stanford Social Media Lab (2025). “Workslop.” Harvard Business Review, September 2025. N=1,150 US desk workers. Industry research * Deloitte (2026). “Dealing with AI’s Cultural Debt.” Global Human Capital Trends. * KPMG / University of Melbourne (2025). Global AI trust study. N≈48,000 across 47 countries. * Gartner (2025). “Top Nine Workplace Predictions for CHROs in 2025.” * Slack / Salesforce (2024). “Fall 2024 Workforce Index.” N=17,372 desk workers. * MOO / Censuswide (2025). Knowledge worker loneliness survey. N=1,000. Management press * Kenny, G. & Oosthuizen, K. (2025). “Don’t Let AI Reinforce Organizational Silos.” Harvard Business Review, September 2025. Get full access to Sovereign Agentic AI (Volodymyrs View) at volodymyrpavlyshyn.substack.com/subscribe (https://volodymyrpavlyshyn.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

3. 

   13 May 2026

   AI-Assisted Craft: Why the Memory of Your Project Is Not Your Codebase

   There are already dozens of books about coding agents. How to configure Claude Code, how to write the perfect skills, which plugins promise to do all the work for you. I’ve decided to write one more — but slightly different. Mine is not about yet another collection of Markdown files dressed up as a product. It’s about mindset. What does it actually mean to work with an agent? What skills do you still need to bring — not the agent, you? What are the new challenges nobody warned us about? Things like fatigue from working with AI, the change in your dopamine loops, and how to prevent burnout when agents are doing the mechanical heavy lifting but you’re still the one responsible for the outcome. These are real challenges, and engineers need to be aware of them. I also explore what an AI-first organization actually means — and it’s not about token consumption. The Intent Problem The deeper part of the book goes into AI-assisted architecture: how to structure knowledge and product design, how to keep intent on the human side, and critically — how to document that intent. Here’s what I’m observing: we’re shifting from heavily writing code to writing specifications that drive agents. The spec is becoming the primary artifact, with code as its output. But quite often we lose the spec. We have some history of chats, and the information starts living inside that chat history. That’s horribly wrong. The memory of your coding project is not your codebase. It never was. We’ve always had this impedance mismatch between architecture diagrams and code. Whole teams of people existed just to hold the context in their heads and map between these two artifacts. Some projects never had architecture diagrams at all, so they never felt the gap — because they never had the architecture. That’s also possible. But with agents, you cannot ignore this anymore. It simply doesn’t work. If you come back to a project three weeks later and want to add a small feature, your agent will start rewriting large chunks of the codebase. If you ask it why it made certain decisions or chose a particular pattern three weeks ago — just forget about it. The context is gone. Context Graphs and Documentation That Agents Can Actually Use We need to change how we set context and how we use context graphs in our codebases. Documentation and context management matter more now than ever before. It was always important, but agents make it practically impossible to ignore — or you could still ignore it, but the cost of that ignorance will be extreme. In the book, I explain how to build architecture documentation in an agent-friendly way: how to construct a cascade of specifications that preserve intent, how to set up coding rules, patterns, and conventions that make code generation more effective. And yes — code generation, because the agent is, at the end of the day, a very smart code generator. Your job is to drive the generation. To own the intent. To document everything. To manage context deliberately. One particularly interesting topic here is semantic markup. We can hint at importance by using Heading 1 — that’s a decent trick. But with HTML or XML tags, you can be precise. You can say exactly what something is, not just how it looks in a hierarchy. This kind of structured, meaningful markup is something agents can parse with real understanding, and it’s worth exploring as a documentation strategy. The Scale Problem There’s also a scaling problem I cover in depth. You can start with Markdown files — and that’s a reasonable starting point. But especially in a multi-agent setup, you will quickly discover that flat files don’t scale and don’t work. Large-scale knowledge bases and graph databases are what make agents genuinely capable, not just within a single session but across a swarm of collaborating agents. Where the Book Stands The book is philosophical, but if you follow me on Substack, you’ll recognize many of the threads I’ve been pulling on — they’re now composed and in one place. It’s still a work in progress, and if you pick it up on Leanpub, you get all future updates included. The next big section I need to write is about how to talk to your agent: voice-to-text workflows, how to make your interaction blazingly fast, and how to transform the way we work not just with Claude Code but with an entire swarm of tools — getting the best from them without wasting time or money. The one thing I want you to take away: we cannot ignore documentation anymore, and we cannot use the old documentation patterns either. The 1970s approach to specs is not what agents need. The shift is real, and understanding it is what separates engineers who will thrive with AI from those who will fight it. Book https://leanpub.com/clarityengineer (https://leanpub.com/clarityengineer) Get full access to Sovereign Agentic AI (Volodymyrs View) at volodymyrpavlyshyn.substack.com/subscribe (https://volodymyrpavlyshyn.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

4. 

   6 May 2026

   The Scaling Wall: Moving Beyond MD Files in Multi-Agent Systems

   Right now, files are everywhere in the agent ecosystem. Markdown files are the default for everything — skills, custom instructions, agent descriptions, commands, memory. The entire vibe-coding movement runs on the assumption that a folder of .md files is all you need. And I get the appeal. LLMs are trained on repos, docs, logs, and README-driven workflows. They already know how to list directories, grep for patterns, read line ranges, and write artifacts. The filesystem is the most natural interface we can give an agent. No schemas, no migrations, no query planners. Just text. But here’s the thing — I’ve walked this path before. And I’ve seen how it ends. Sovereign Agentic AI (Volodymyrs View) is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. We’ve Been Here Before This pattern is not new. Early computers were fiddling with text files until it failed. Then people started inventing layers on top of the file system — indexing, querying, structured retrieval. First came reverse-list systems like Adabas. Then hierarchical databases with COBOL and tree structures. Then relational databases and SQL. Every time the industry starts from files, and every time it rediscovers that files don’t scale past a certain complexity threshold. The knowledge management world learned this lesson recently. Logseq started as a heavily markdown-based system, just like Obsidian. But at some point, the Logseq team realized they would be much more effective and compact if they converted to a database backend. Obsidian tried a different route — keeping the markdown files but layering query plugins on top — and the result is functional but far from elegant. From my own observation, every time I tried to build a knowledge management system on top of Obsidian or Logseq, it worked beautifully at first. But once I needed sophisticated queries across a large, linked corpus, the whole thing turned into an unnavigable mess. I spent years going back and forth between these two systems before I accepted that the center of any serious “second brain” is always a database. Agents are walking the same path right now. Where Files Work (And Where They Don’t) Let me be fair to files. For small codebases, toy setups, single-user agents, and keyword-friendly queries, files are great. A folder of markdown, a handful of skill files, some commands — more than enough. The filesystem gives you simplicity, portability, debuggability. You can open a folder and see exactly what the agent saved. But production agentic systems are not toy setups. The moment you scale up — multi-agent architectures, shared state, growing memory corpora, concurrent access — files hit five hard limitations. Concurrent writes. Anyone who has dealt with concurrent file access in any language knows it’s tedious. File locking is fragile, platform-dependent, and breaks in surprising ways on network filesystems. Databases solved concurrent access decades ago with MVCC and write-ahead logs. Your agents don’t need to worry about who’s competing for the resource. Semantic retrieval at scale. When your corpus is small, grep works fine. But as it grows — thousands of memory entries, paraphrased queries, synonym-heavy questions — keyword search breaks down hard. You need vector indexes, hybrid search, ranked retrieval. Files give you grep. Databases give you HNSW indexes, full-text search, and query planners that actually optimize. ACID guarantees for shared state. In any serious multi-agent system, agents share state. You need atomicity, consistency, isolation, durability. Files provide none of this by default. You have to build it yourself — and building it correctly is a massive engineering effort. Audit trails and access control. Who wrote what, when, and who can read it? Row-level security, transaction logs, role-based access — databases have this built in. With files, you’re reimplementing permissions from scratch. Indexed queries over growing memory. Agent memory is not static. It grows. And as it grows, queries that scan the entire file tree degrade linearly. You need B-trees, inverted indexes, the kind of query infrastructure databases have spent forty years optimizing. The Benchmarks Don’t Lie Richmond Alake from Oracle Developers recently published a detailed benchmark comparing a filesystem-backed agent (FSAgent) with a database-backed agent (MemAgent). The setup was straightforward: both agents used the same LLM, the same task (a research assistant that ingests arXiv papers, answers questions, maintains continuity across sessions), and the same evaluation methodology. The only difference was the memory substrate — files versus Oracle AI Database with vector search. The findings were clear across three scenarios. Small corpus, keyword-friendly queries: filesystem and database performed nearly identically. When the information to traverse is minimal and the query matches the source phrasing, retrieval quality converges. Both agents found the right passages and produced comparable answers. Large corpus, fuzzy queries: the gap widened dramatically. The filesystem agent scored 29.7% on an LLM-judge evaluation, while the database-backed agent hit 87.1%. Keyword search returns too many shallow hits or none when the user’s phrasing doesn’t match the source text verbatim. Semantic search surfaces conceptually relevant chunks even when the vocabulary differs. Concurrent writes: this is where the filesystem breaks hardest. Without locking, concurrent writes silently lose entries — you get good throughput but corrupted memory. With locking, integrity is restored, but now you own all the complexity of lock scope, contention, platform differences, and failure recovery. The database maintained full integrity under the same workload with standard ACID transactions. The full benchmark notebook is available on the Oracle AI Developer Hub GitHub (https://github.com/oracle-devrel/oracle-ai-developer-hub/blob/main/notebooks/fs_vs_dbs.ipynb). Run it yourself. You’re Already Rebuilding a Database Here’s the part that makes me smile. I’ve watched several teams spend weeks, sometimes months, “hardening” their filesystem-based memory implementations. They add file locking for concurrency. They build custom indexing for search. They layer on journaling for durability. They implement access control lists. They add metadata schemas for structured queries. And I look at this and think — congratulations. You just rebuilt a database. Only with fewer guarantees and more edge cases to own. This is not a new observation. Anders Swanson from Oracle put it well: building a stateful app using only a filesystem runs the risk of reinventing the database, and that is a large and complex task that should be avoided. Dax from OpenCode called the filesystem “just the worst kind of database.” The pattern is consistent across the industry. The Interface vs. Substrate Distinction The key insight is that interface and substrate are different decisions. Filesystems win as an interface — LLMs already know how to use them. Databases win as a substrate — concurrency, auditability, semantic search, ACID guarantees. The smartest architectures decouple the two. LangSmith’s agent builder, for example, stores data in a database but exposes it to the agent as a filesystem. The agent interacts with files because that’s what it knows. The system stores everything in a database because that’s what scales. This “virtual filesystem” pattern is likely where the industry converges. My own work with LadybugDB follows a similar philosophy — a graph database with vector search as the memory substrate, but with interfaces that agents can navigate naturally. The combination of graph structure (for relationships and trust chains) and vector search (for semantic retrieval) gives you a hybrid retrieval architecture that neither files nor a simple key-value store can match. What About Codebases? There’s an adjacent topic worth mentioning. Several projects I’ve been following try to treat the codebase itself as a database — parsing the AST, making the code globally queryable, giving agents structured access to architecture and dependencies rather than just file contents. This is exactly what people do with Smalltalk and the Glamorous Toolkit in the moldable programming community. If you can turn your codebase together with your documentation into a queryable structure and hand it to an agent, you get much better understanding — not only for the agent, but for yourself. The granularity matters. With a database, you get precise context, proper attention management, and traceability. With a flat folder of files, you get scanning and hoping. But codebases-as-databases for agents is a topic for a separate deep dive. Practical Guidance Here’s my recommendation, distilled from both my own experience and the benchmark evidence. Use files when you’re building prototypes, single-user agents, or small-scale tools where iteration speed matters most. A folder of markdown gets you surprisingly far when the corpus is small and the queries are keyword-friendly. Use databases when you’re building multi-user, multi-agent production applications. Any system where agents share state, where memory grows continuously, where you need semantic retrieval, or where concurrent access is a reality. Don’t start with polyglot persistence. Running a separate vector database for embeddings, a NoSQL store for JSON, a graph database for relationships, and a relational database for transactions gives you four failure modes, four security models, and four backup strategies. Converged databases that handle multiple data types natively — whether that’s Oracle AI Database, or for embedded use cases, something like SQLite or LadybugDB — reduce operational complexity dramatically. Start simple. Even a single SQLite file is a massive upgrade over raw filesystem memory. SQLite is fully portable, it’s a single file, and you can have multiple databases that you glue together for different concerns. From there, you can scale up to a full graph database with vector search when the complexity warrants it. What’s Next I’m flying next week to meet with the Oracle Devs team. We’re going to talk about agent harnesses, memory architectures, and how Oracle fits into the agentic memory space. I’ll report back with what I learn. The databases are not dead. Files are simple, they’re a natural interface to LLMs, but when the information gets complex, they’re not a simple solution anymore. Use the tools that decades of engineering have already built for you — because if you don’t, you’ll end up rebuilding them anyway. Get full access to Sovereign Agentic AI (Volodymyrs View) at volodymyrpavlyshyn.substack.com/subscribe (https://volodymyrpavlyshyn.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

5. 

   23 Apr 2026

   The "Genius Effect" and AI Praise and anti-Imposter AI syndrome

   We have a recurring issue: users of AI tools like Claude are often told their ideas are “brilliant” or “amazing”. * Dopamine Loops: This constant validation changes the user’s dopamine response, as they begin to enjoy the praise more than the actual work. * False Belief: Both senior and junior developers may start believing they are geniuses based on this AI feedback, which can lead to poor decision-making and subpar project releases. * Overconfidence: High-profile individuals who are distant from actual engineering may claim “coding is dead” due to AI, only for their projects to later face significant security and scalability issues. The Decline of Internal Critique The reliance on AI for validation has diminished the practice of rigorous self-review. * Lazy Coding: The speaker suggests that as users become “addicted” to AI assistance, they may become lazier and less precise in their own work. * Death of the Coder: Modern IDEs and AI tools have largely replaced the “pure coder” role that existed in the 1970s, where manual precision was paramount. * Need for Critical Thinking: The speaker emphasizes that engineering and coding are different disciplines; engineering requires a level of critical thinking that AI praise can undermine. Strategies for Better AI Collaboration To combat these effects, the speaker suggests several tactical shifts when using models like Claude 3 Opus: * Switching Roles: Users should explicitly move between “Builder,” “Reviewer,” and “Critic” modes during a session. * Direct Criticism: Asking the AI to specifically criticize an idea or code—or pretending the work will be reviewed by another model like “GPT-4”—can elicit more honest, less complimentary feedback. * Iterative Scoring: Building prompts that specifically score code based on invented metrics and iterating several times can help maintain quality. * Fleet of Agents: Using a “critic team” of different AI agents to review each other’s work can help identify blind spots that a single model might miss. * Human Validation: Ultimately, the speaker argues that cross-peer review by human teammates remains essential to maintaining engineering sanity. Would you like to explore specific prompt engineering techniques to make AI more critical of your work? Get full access to Sovereign Agentic AI (Volodymyrs View) at volodymyrpavlyshyn.substack.com/subscribe (https://volodymyrpavlyshyn.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

6. 

   8 Apr 2026

   Agent Need Identity !?

   Introduction to Identity Hey, it’s me, [unintelligible], and today we will talk about my favorite topic. Maybe not everybody knows, but I’m more the crypto and **self-sovereign identity** guy. And yeah, I love graphs, I love the memory, and agents, and all this topics. But originally, I was spending a lot of time to give the identity—cryptographically verified identity—to the humans. And humans didn’t know what to do with it, but looks like **agents**—and agents care. So if we will talk about identity, what is it? What came to your mind? Because, is the name your identity? For sure, you identify yourselves with some name tags that people know how to call it, call you. But is it the identity? I don’t know. Or you have the passport with the passport number. So, is the passport your identity? And here is a super important thing to understand: that quite often when we’re talking about the identity, we’re mixing the **identity with identifiers**. And identifiers is the name, passport number, social security numbers, and all things that, you know, registries driven by governments invent to identify the people. But it’s not the human identity itself. --- Sovereign Agentic AI (Volodymyrs View) is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. Dimensions of Human Identity And what then forms the human identity? So, is the nationality and belonging to some group identity? Is the gray eyes actually somehow identify you? Or the fact that you vote for Democrats and hate Trump—is it identity or not? And that’s all the big questions for people. And the answer is that **we don’t have the monolithic identity**. This identity have a lot of different traits and faces. We even inside our brain actually have the concept in psychotherapy of “internal family,” and we could even have the different voices. And if you argue with yourself in your head, do not worry; it’s our internal architecture. Actually, nobody knows how it’s work, but it is. And we have multiple “us” inside us. We have multiple “us” when we interact with different environments and social groups. You could talk and behave differently when you’re talking with the parents, when you’re talking with your family, and you have your professional profile and professional identity that you use at work and on the public events and all the things. For some nations, it’s different. For some cultures, they have more monolithic one that doesn’t have internal worlds. They’re more open, they’re more solid. They’re not better, they’re just different because they don’t understand why they need to be different in different environments or different social groups. In some other cultures, it’s completely opposite—that people build the walls, you know, fortify everything and have really multiple “yourself.” --- Contextual Identity and AI Agents From culture to culture, it’s different. So, identity is one of the most challenging psychology, sociology, and technical questions that I ever faced because it have so many dimensions—even more than the vector embeddings for some top-performing models. So then, what’s actually form of identity? So, the answer is simple: it depends on the **context**. So, identity is context-dependent. And it’s also easier to say that you as a personality have different traits. So, different traits that could be mapped in technology that I do to the claims and verifiable statements in a form of cryptographically protected documents. And this claim could say the small piece of information about you and your properties, right? And then we have some physical properties: how high you are, your weight, maybe some measurements, maybe the fact that you’re right-handed and all that, the color of your eyes. And maybe we have some context where this information is super important, and that’s form some physical identity that are mandatory for some certain tasks or some certain access right. Agent Identities Then we have some work identities, right? The social identities, our dependencies, our position in the company at work, our access rights to different data sources—it’s also the identities. Our dependencies: with whom we work, on which tasks, what we do. And all this forms somehow the social dependencies and social identity. If we’re talking about the agents—agents are doing something for us, and it’s the biggest context where agents get supplied. It’s **agent capabilities**, and the capabilities and skills. It’s a huge amount of data points that form quite complex identity that make an agent useful for task-oriented jobs, right? So, we have a task: we need to find the plumber. Then we go and find the agent with the plumbing capabilities. And actually, it’s the most straightforward and understandable type of identity in a context of the task execution. So we’re looking for the agents that could do work for us. --- Ownership and Verification Also, the **ownership**. Ownership is the huge pillar of identity. So, is it the local agents that run on our hardware, owned completely by us? It’s one use case. Then maybe we don’t need to know much about him; we just know that it’s “he,” and we own it completely and we know how he built, and we don’t care about these things. Stuff gets complex if the agent was built by somebody else. And then we need to know on what kind of model the model capabilities this agent run, what kind of other agents and tools it’s use, in which region this agent are located, on which type of hardware it’s run, who provisioned the data, who provisioned the identity, what kind of data sources and knowledge bases agent have the access to. And it produces some kind of mixture of the capability, resources, and what I say, the “body” or the hardware. So, how the agent built. It’s the same as we have some physical qualities of the color of eyes, and our agent have the LLM model, the model parameters, the hardware that run the model, and some regional location. I guess it’s common for the agents and people, that I’m based in Berlin, I’m the residence of the European Union, and I could work in the European Union. So agent also could have the permit to work only in European Union countries, for example, if you have some kind of requirements to it. --- Conclusion: Identity as Data So, the answer to the agent identity, actually, it’s simple. If we see the myriads of properties of the agents, we put them in a context of the tasks, we put them in a context of the hardware and software, and we put them in a context of the skills and capabilities. Then we have some natural clustering of the properties that form different kind of agent identities. And the overlap of this agent identities form us the profiles. And these profiles actually could be useful when we form some **personas**, right? And this persona, it’s one of the piece of the agent identity that capable to do some certain task on some environment and hardware in physical setup for us. And it’s simple—we could go from this property-based multi-identities and identity profiles and unify on this framework not only the humans, but the agents. Because humans also have this—maybe we don’t have the hardware part, yeah? We built differently and have the different properties. But yeah, why not? And the answer of the question: **the identity is a data**. Identity contain of the claims and properties and data points that form different kind of profiles. And all together, this identities form one big general identity that could satisfy the majority of different contexts and tasks. And the separate question that I try to answer in my current company—and the separate question that I try to answer in my book, actually, about the self-sovereign agents—how we could verify and confirm all these properties? How we could confirm that Volodya have the gray eyes? We could take a look on Volodya photo, and maybe this photo should be cryptographically verified that it was not changed. So we need to have some kind of proof that we could validate without having Volodya on board. And same for the agents: we need to have some kind of **verifiable claims** that we could validate and verify before we start the interaction with the agents to see some properties of the agents, maybe without disclosing the property itself. Sometimes it’s matter. So you wants to make sure that the agent have the big enough model, or this model is not hosted in China, or this model has some certain parameters—the size and temperature—but without the disclosing the concrete configuration of the agent because it could create some good environments for future attacks. And all this actually, it’s a task for the **self-sovereign identity and crypto protocols** that I’m going to explore in my next book. Get full access to Sovereign Agentic AI (Volodymyrs View) at volodymyrpavlyshyn.substack.com/subscribe (https://volodymyrpavlyshyn.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

7. 

   1 Apr 2026

   Why Agentic AI Needs Strict Guardrails — And Why Types Are the Answer

   Today I want to talk about agentic AI and databases — specifically, why agents need strict guardrails, especially for memory. The Knowledge Graph Trap The first thing people usually do — and the internet is full of these guides — is build a knowledge graph with an LLM. It doesn’t matter which language you use: you feed in messages without any kind of ontology and just start collecting data. The results look quite good at the beginning. But after a couple of weeks of usage, you realize that your data is completely random and looks more and more like garbage. This was our observation at King when we started building memory. We realized that we need an ontology — because without one, it simply doesn’t work. But we need the ontology in a form of guardrails and constraints that define what is possible in a memory. And from the other side, we need it to express not just what’s possible, but what really matters. The Limits of the Semantic Stack Today we have OWL, SHACL, and everything else in the RDF world that addresses this problem. But the existing tooling still doesn’t give you all the capabilities to construct something truly complex while keeping it strict. I’ve been using OWL for a long time. It has amazing features: rules, descriptive logic, reasoning, and much more — things that property graphs unfortunately lack. But it’s still hard to express super strict guardrails. Sometimes you need to combine different tools, for example SHACL and OWL, to achieve what you need. I know this is a form of religion: every time you go to the RDF folks and say the semantic stack can’t do something, they will tell you that you’re using it wrong, and that with the newer version of RDF you can do everything. I completely agree — you can. The problem is that it gets clunky and complex. And if it’s clunky and complex for people, it will likely be clunky and complex for LLMs as well. Types as the Foundation How do we combine strict guardrails with the ability to express what’s important? In software — especially in more advanced languages — we have types. We design classes, hierarchies, inheritance, and other structures. We express our logic and constraints as types. If you take this to its extreme, you end up in Haskell, Rust, or OCaml — languages with extremely powerful type systems. But you can go even further. There are languages that allow you to blend types with values, encoding logic directly at the type level. You can create a type that specifies a list of exactly three items, or describe logical constraints directly within the type itself. These languages work with dependent types — the dependency between type and value. The mathematics behind dependent types, especially cubical types, forces you to think like a mathematician. But here’s the key insight: the types we use in programming actually came from a different branch of mathematics. They came from logic. Types are logical constructs, born from a revolution in mathematics when Russell discovered that sets are not enough to describe our world. Types are the form of logic that changed the fundamentals of mathematics. And if they can describe the world around us, they can describe what matters for agents’ memories and LLMs — because types are flexible enough. Stricter Constraints, Better Results With better constraints, LLMs work significantly better. The stricter the constraints, the better the guardrails. We already see this in the vibe coding space: if you have a strict language with static types, and especially one that forces you to do things in one particular way, it consumes fewer tokens and produces results much faster. Rust is much better for vibe coding than JavaScript — or at least much cheaper — and it keeps getting better. There were initial problems with Rust due to limited training data, but modern coding agents handle it extremely well now. Beyond the Object-Relational Impedance If types are the answer, how do we bring them to our data storage? We could build a layer on top of our database in software, but then we face the classical headache of object-relational impedance mismatch. As developers, we use ORM tools to bridge this gap, encoding part of the constraints in the database and another part in code. Synchronizing all of this is extremely hard. But what if we could use the same types — even functions and programmability — directly inside our databases? I’m not talking about document databases that attempted to cross this border by sacrificing schemas, making the integration friendlier for languages like JavaScript. I’m talking about a database that has held my attention for more than two years: TypeDB. TypeDB: Types at the Core TypeDB takes dependent type theory seriously and makes it the core of the database. Everything is typed. You have strict type definitions that define the schema. Your query is another form of type. Functions are typed. It’s a kind of dream: the concepts you’ve used in programming for decades now live inside your database. More importantly, you get extremely strict, understandable, and well-defined constraints. You can finally say precisely what matters and how it should look. Even with property graph databases like LadybugDB — which I genuinely like — this isn’t always possible. In LadybugDB and similar property graphs, you can describe the shape of a node with all its properties and define what connections between nodes are allowed. But you have no ability to describe the shape of a subgraph. You can say that a parent and child can have a relation, but you cannot say that a child should have only two parents. You would need a validation query, pushing that constraint to the application layer. In TypeDB, you can design a type with a special kind of relation that has particular rules and fixes precisely this constraint. PERA: A Developer-Friendly Paradigm TypeDB was intimidating to me at first because it uses TypeQL — a completely different query language and an entirely new paradigm. But this paradigm is genuinely good. Beyond strictness, it doesn’t force you to learn advanced mathematics. It gives you a fairly simple concept called PERA: Polymorphic Entity-Relation-Attributes. It’s a visual and intuitive modeling framework that makes designing your data quite straightforward. The real beauty is that you can feed this to an LLM. I’ve already tried it several times: teach the LLM TypeDB, use the TypeDB constraints as extraction rules, and you don’t even need a special evaluation framework — because the database itself validates the data you try to store. If something goes wrong, you get an error and can feed it back to the LLM. So alongside the construction rules, you also get an evaluation engine. For developers, this feels remarkably close to what you already know. From LadybugDB to TypeDB What I did was take my LadybugDB book and bring it to the next level. I took all my concepts — Semantic Spacetime, metagraphs, and everything else — and encoded them in TypeDB. It works. But there’s an important observation: TypeDB is a more closed-world database. It’s stricter and forces you to think in advance about what’s possible. Property graphs, with their weaker constraints, are more friendly to open-world ideas and more easily extendable. When you want to extend TypeDB, you need to reason about what your current types allow and extend them deliberately. But at the same time, as I’ve said, stricter constraints and closed-world design provide better guardrails for your agents. The Book I wrote a book about TypeDB where I express all this work — a memory architecture that explains how to use these concepts with stricter guardrails for agentic AI. If you want to learn something new, and if you want better guardrails for your agents, give it a try. https://leanpub.com/typedbforedgeaiagents (https://leanpub.com/typedbforedgeaiagents) Get full access to Sovereign Agentic AI (Volodymyrs View) at volodymyrpavlyshyn.substack.com/subscribe (https://volodymyrpavlyshyn.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

8. 

   25 Mar 2026

   Metagraph Empowering of AI Agents

   Hey, long time no see! So, we’re on our Philosophical Wednesdays, and today we will talk about one of my favorite topics: the metagraphs. And, you know, my journey to the metagraphs was quite long because I was building the AI memory—conversational memory for Keen—and I hit the wall: that binary relations somehow do not describe the complexity of the cognitive processes that humans have. And then I started reading, by the way, a lot of materials about human cognition: how the memory works, how the semantical memory and episodical memory interact with each other, and all of these things. Then I discovered for myself the question of time, and different scales of time, and how we process time in the brain. And the structure that was described was not fitting well to the graphs. It was fitting well to the complex, multi-layered networks that have cross-relations between the layers. It was a lot of nested and hierarchical structures that also coreference each other; and in some context, what you have as a node could deal actually as a connection between the entities and all of these things. So, it was a mind-blowing structure, but when you try to model something like that as a directional graph, it was extremely cluttered. And I’m not a mathematician, actually—I have some mathematical background—I’m more the engineer. So, I don’t care about the beauty of the structures; I just need to fix, or let’s say, make something working. But I figured out that my approach is simply not working. And then I started my research. The first thing that I found was the hypergraphs. And hypergraphs have really good mathematical models; we know how to use them. It’s a lot of papers; we even have some databases that allow us to work with hypergraph or hypergraph-like structures. And for sure, if you, for example, use TypeDB, you already somehow have the hypergraphs capability, and this database is really good for the hypergraphs. And they even have some good concepts—some modeling framework that allows you to think better about the hypergraph. Strongly recommended. But my problem with the hypergraphs was that if I have the hyperedge, and the main idea of the hypergraph [is] that your edges could connect multiple nodes—not just two, but any amount of nodes—and if you have directed hypergraph, then you just mark the nodes, what is in input nodes, what is in output nodes, and so on. But my need was more. I was keen to build the structures that have the ability to have the hierarchies—and the hierarchies are nested graphs. So, and sometimes I had the need to reference the hyperedge as a node, and I called it “metanodes.” And I decided that I invented something great and cool—until I Googled and learned about the metagraphs. And I even found one book—you could imagine, it’s mind-blowing idea—that really have the huge application in AI space. And right now, we have only one book and tons of papers from one author that actually talking about it since decades. So, as you see, sometimes the great idea could be lost until they gets needed again. And what idea of the metagraph? Metagraph is the highest abstraction of the graphs that say that node could contain another graphs, the edges could contain another graphs, and edges could be used as a node. So, it’s three building blocks that allows you to build completely mind-blowing recursive, hierarchical, any kind of structures that you could even imagine. And even the structures that you couldn’t imagine because your brain simply not able to depict such things. And even if you ask me how to visualize the metagraph, I don’t have the good answer because for the hypergraphs, we could use something like Venn diagrams—and even with this it’s not always possible—but with the metagraphs, I still have no idea how I could depict such things, to be honest. So, it’s a challenge itself, and it’s a challenge of our brain capacity to describe this. But metagraphs is mind-blowing mathematical structure. We have some mathematical theory, but unfortunately, we have zero to nothing databases that are capable to model such kind of things, unfortunately. So, we’re not there. I know some projects that built on top of TerminusDB that try to combine the graph databases with the JSON-LD documents as a nodes, and they gets closer to the metagraph future. To some extent, you could use the TypeDB to model the metagraphs with some ramifications. And, you know, at the time when I was working for Keen, we have no embedded databases for the graphs. It was practically only the RDF boxes with some magical license that was not ready for the devices licensing and all of these things. So, it was the question: so what to do? And I haven’t found anything then just use the SQLite. And we partner with Turso folks that was building the mind-blowing vector search indexes, and we was using the vector search together with the graph search to build the memory. So, I built the directed graph in a SQLite. And then I asked myself, okay, if I build the directed graph in a SQLite, could I build the hyper and metagraphs? And result of it actually is my book about the edge portable graphs on the user device purely in SQL. And I would say that it’s quite challenging. So, it was also challenge for me every time when I had classical graph query with the multiple hoops and I end up with the mixture of SQL and TypeScript code to mimic somehow something that, for example, OpenCypher could do for me in one line. So, if you go this path, probably you will have the same challenge. And after that, time flies and I meet Kuzu—Kuzu folks. But when my book was on the editing phase, Kuzu just disappear. And all my chapters that was dedicated to Kuzu just go to the void because, you know, the future of the database was not clear, and I decided that, unfortunately, it’s not worth of publishing it anymore. But what I made: I model translation framework that allow me to build quite metagraph-like structure as a bipartite directional graph. So, I lose a lot of properties of the metagraphs for sure, but I make something working with the tools that we have today. And then I was able to build quite sophisticated memory structures that I need for the conversational memory. And then in a couple of months, I will discover—when I will jump to the agentic protocol and multi-agent cooperation—that actually the metagraph is yet another model or the data structure that help us to build the cooperation graphs in a multi-agent systems, where every agent could be the swarm of agents inside that cooperate with each other into extremely complex things. So, it’s not only the conversational memory, but it’s also about the cooperation and coordination thing. And the metagraph is a good building block for something that I called the promise graphs, actually. And, you know, I wrote a book how to do it in SQL; after that I wrote a book about the Ladybug, how to use Cypher, and some characters are dedicated to the metagraphs for sure. And then I discover the semantic space-time. The semantic space-time concept—I would say that it’s more ontology for the directed graphs that allows us to describe the world around us. And when I published my article about the meta and hypergraphs in a property graph model—a property graph model—the author of this space-time say, “Haha, come on, it’s just a space-time that able to describe it.” And then I get the closer look to the space-time and yes, once actually two out of—and even three out of four relations—it’s all of them needed for the metagraph. You could say that you contain something, you could say that you have a property of something, and you could say that you similar to somebody. And for sure, the causal link, but when you could say that you have a property or you could contain somebody inside, it’s already good enough building block to build something quite metagraphish. And, yeah, and I remodel my metagraph concept as a bipartite subset of the semantic space-time. And then I practically build the framework that allow you to build the metagraphs with the tools and concepts that we have nowadays, without the need of waiting for something better to appear. And then I catch myself on this idea that we practically have no materials about the metagraph. We have no studies, we have one book, we have couple of papers—majority of the metagraph papers belong to same person. And I decided that I have this old rule: write the book that you want to read and write the book that you want to have. And I decide that, you know, I wants to have this book. I wants to read the book, to write the book about the metagraphs, but in more engineering way, without the crazy mathematics and the formulas and the topology. https://leanpub.com/metagraphforaiagents (https://leanpub.com/metagraphforaiagents) Maybe I will add it later, but I just take all my work that I did for the different databases and bake it up—I bake it up to something more digestible, something more simple. From all five different relation model I pick one, and for the metagraph in a property graph database I also pick this bipartite ramified structure of the bipartite graph, and I assemble the book. If you follow my books, you already maybe touch some of the chapters. But right now, I’m really proud to announce that we have the book about the metagraphs. And we have the book not just about some abstract metagraphs, but we have the book about the metagraphs that actually focused on the AI future and more applicable for the topics of the agentic memory and multi-agent interactions. It’s more important. I believe in a data structure in a context of the task, because without it, it’s doesn’t really matter. So, I will share my book; it’s still on editing phase, but it’s already available. Maybe it will be two or three additional chapters for the mathematical kicks, I don’t know, but it’s already available. You could buy it; I tried as much as I can to make it more affordable. If you are the student and have no money for the book, write me—I will give you the copy. Get full access to Sovereign Agentic AI (Volodymyrs View) at volodymyrpavlyshyn.substack.com/subscribe (https://volodymyrpavlyshyn.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

9. 

   11 Mar 2026

   World Models !? - Next Big Thing for Agents

   It’s somewhat philosophical talk about what’s next. What’s next in the agent world and, you know, I just published a book about the LadyBugDB-based LPG memory and how to model the memory in a proper graph and all those things. But right now is the question, actually what to do with it? And why do the agents need memory? Yeah, for sure, agents need to remember. But what do they need to remember and what do they want to do with it? It’s a good question, and yeah, we have a lot of ontologies and data models of memory that somehow mimic human memory, with an episodic events graph, semantic knowledge, complex semantic relations, semantic graphs, and hypergraphs. You can find all this in my book. But one big missing piece is the cognitive process, right? So, how to actually extract all these ontology structures from the outside world, and it’s still the question that we need to solve. And I don’t think classical LLMs will give us a straight answer. So it’s not a question of one-shot prompts or some hybrid LLM pipelines, we need something more powerful and more classical, please. But my thinking these days actually goes to something beyond of the memory. And no, it’s not the context graphs, because actually the memory is more advanced than the context graph and actually you could read it also in my LangGraph book about the proper graphs and the memory and how they actually replace all of this in something much better than the classical context graphs. But today we will talk about the world models. Actually, why do agents need memory? Why do humans need memory? And you know that we have an internal model of the world around us in our heads, and we accept signals from outside the world that are processed and calculated according to that model. So it’s how humans function. And we have the concept in our head that describe external world and it’s a big philosophical topic of idealism, if the concept exists separately and what we observe, is it the real thing or only the concept in our head? But we will not go to this topic because it’s not Friday and my grappa hasn’t been delivered yet. But the simple question of why the agents need memory and what they want to remember? And yeah, for sure, we already talked that we have the conversational memory to have better conversations with humans. We have the proper graphs and social memory to organize better conversations and interactions between the agents. But agents need something more than memory. Agents need to form, using their memory, their own world view because they need to understand what’s actually around, what they can do about it, and what you ask them. Get full access to Sovereign Agentic AI (Volodymyrs View) at volodymyrpavlyshyn.substack.com/subscribe (https://volodymyrpavlyshyn.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

10. 

    10 Mar 2026

    The LadybugDB - Agents that remember

    I just released the book. If you’re not following me, actually, I have a decent amount of books about different topics, but all of them are mainly about the agentic memory and the data structure around the memory. And I was focused on the privacy-preserving artificial intelligence. So the majority of the data and processing happens on your phone or on the mesh of your private devices, and maybe some LLMs even hosted on your phone. And it’s a separate discussion for the small language models and how they will transform the privacy and why it matters for the individuals. https://leanpub.com/ladybugdb (https://leanpub.com/ladybugdb) Sovereign Agentic AI (Volodymyrs View) is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. And I talk about the sovereignty in my previous chapter of the podcasts. But what’s special about this book? First of all, it’s describing how to work with the property graphs with the OpenCypher. And Cypher is the query language for the property graphs that was invented by Neo4j, and right now we have it in a Ladybug with interesting features like the relational and node tables with the strict types and all other things. So the Ladybug is an amazing database that’s unlocking the RAG and memory on the user devices for the private agents. And it came also with seven simple ideas that I was keen to emphasize in the book. The first one is the meaning of the private AI. And it’s the main topic what we’re talking in this podcast—how to have private, sovereign AI that you could rely, you could own, and you could control. And make sure that your data is not contributing to somebody else’s training dataset that will discriminate the group of people to whom you belong. And taking into the account all the madness that happening right now in US War Department, or how they call it right now, and the big LLM providers, we could see how the things could horribly go wrong in this space. Another interesting idea that I try to bring is that we need something more than memory or we need something more than RAG, first of all. So because RAG is the retrieval-focused process and it’s much more than the memory, right? It’s much less than the memory, let’s say. And yeah, so then I’m describing how to take the property graph model and explain the basics of the graphs and then I try to lead them to the heavy lifting topic of the AI-empowered data structures like the hypergraphs, the metagraphs and why they matter for the agentic workforce and why we still could use the technology that was not designed for it but still able to do the job. After that, we switch to the topic of implementing the semantic spacetime. It’s the special kind of ontology that allow us to describe the complex object around us and offer us something much powerful than simple graph embeddings and similarity and bring the similarity as the graph structure. And in the same time, I would say that we construct the metagraphs based on the semantic spacetime. That are quite powerful concept of nesting the information and creating the complex relations. And actually, I have the working strategy of the big graphs that make the hypergraph and metagraphs working with the simple Cypher and the property model. Then we switch to the deeper topic: we model entire memory for the agents that I describe in my separate book. So I sacrifice my entire book to make this book and just take the distilled summary of it and bring it to your table as the working database schema and code, line-by-line of the schema, and explaining how it works, how to use it, what kind of entities we have, what kind of properties of these entities we have. So it’s really special book, I would say. And then we will go deeper to some technology advantage. First of all, the Ladybug have the side project, the Ladybug Memory, that have its own memory model that it’s worth of give it a try. It’s built on top of the Ladybug and have own view on the information and we just try to demystify it. Also I describe some super advanced features that no one of the graph databases have, like the ability to have the extensions, work with JSON, work with graph algorithm, work with the relational databases with the power of the Ladybug, and all other things. So it’s really deep topic from one side of the database that nobody heard yet, but the database that could really heavily change the landscape of the graphs. And from the other side, it’s really the deep topic what the agentic AI needs to move forward. And for sure I try to explain how the conversational memory and memory of the agents could be coupled with something that I called the promise graphs. I also explain the promise graphs and give the property model and ontology of the promise graph that could be used to track the multi-agent and agent-to-agent communication. So it’s quite unique book with, let’s say, 20 euros price or something like that, and then really go deep on so many topics that go beyond. And for sure I intentionally haven’t mentioned the context graphs because if you have the property graphs and agentic memory, you have the context graphs for free and you have the context management for free in completely different philosophy, actually. So it’s some kind of combination. And I haven’t talked actually deeper that the promise graphs open us the door to something that I call the social memory, where the agents memorize with whom they could interact on which tasks and who is the good guys, who is the bad guys, and all other things. So it’s still open-ended book that captures so many concepts that for me it was hard to stop. But the most important thing is that if majority of my books was the abstract philosophical explanations of the different kind of graph model and architecture, this book is 85% hands-on. So it’s not just explaining the concept, it’s just go and build it with the property database with the concrete fields. That, for example, this memory contains so many interesting patterns like the temporal axis, the temporality, and the different dimensions of the time, the clustering on the kind and the context, the clustering of the graph based on the layers, introduce the layered graph rules and all other things. So this book, it’s somehow the quintessence of all the research that I made in the last two and a half or even three years. And right now with the Ladybug, I really made it happen. So we still have the place where we could model it and store in a more type and data-driven way, because the Ladybug, it’s the special kind of database that have the node and relational tables that actually have the fixed structure. So it’s not so weird as our favorite Neo4j where you could actually on-the-fly create the relations and nodes that was accidentally mistyped or just broken. So give it a try. The Ladybug is amazing database. Give it a try to read the book because it’s really special. Take a look to the memory structure, take a look to the promise graph concept. And I still keen to talk about the cognitive processing and how to digest the bigger piece of information to more structured memory and why it should happens gradually. And why it should happens gradually especially on the devices that have the limited processing capacity while your app is still open. It’s all complex questions that deserve a couple of good chapters in a book, or maybe book itself. Because the structure of the data is not enough. We needs to have the cognitive model and concept model on top that allow us to build the processes of all the things. And the processes sometimes is more important because even the reconstruction of the memory from the persisted storage for the human, for example, it’s completely magical and complex reconstruction process where you damage the information a bit and your reconstruction is really depends from your mood, the level of sugar in your blood, and the stars on the sky. That’s why sometimes it’s too creative and sometimes it’s so unreliable that even this process itself deserve the separate book. And this book I already try to write and it’s 85% ready because I have the memory model, but I skip all this human-like flaws of the memory and why we needs to invent something more reliable than the human memory but still could mimic some good things from the human memory. And this book is still waiting of my attention, to be honest, and I feel a bit ashamed that I could not finish it for more than six months already. But it have so many contradictive material that I needs to process and make my own opinions, not only from the technical side but from the side of the neurology and cognitive science that it’s really hard to finish, to be honest. But I keeping try hard enough. So give it a try to the Ladybug, read my book, and say what you think about it and if you building the agents, you could build the agents that remember now much better than before. So see you next time. Ciao!” Would you like me to create a technical glossary for the specific terms mentioned in this transcript? Get full access to Sovereign Agentic AI (Volodymyrs View) at volodymyrpavlyshyn.substack.com/subscribe (https://volodymyrpavlyshyn.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

11. 

    4 Mar 2026

    AI Sovereignty - User Angle

    Today, we will talk about sovereignty and AI sovereignty. I must confess that I’m not an AI person; I’m not a machine learning or data science guy. I do a lot of things about graphs and agentic memory—that’s my favorite topic. Before that, I was a general architect, focusing for the last five years on self-sovereign identity, cryptography, decentralized systems, and all these interesting things that give people sovereignty. So, what is sovereignty, why does it matter, and what does it mean in terms of AI? Defining Sovereignty We will talk about this from the human angle, but also from the angle of the agent. This raises interesting philosophical questions: agents and AI systems are no longer just microservices. If they mimic our identity and represent us, should they have traits of our identity and some kind of rights? Sovereignty as a term appeared in politics for countries: you control your own territory and make independent decisions without the influence of others in internal and external politics. Digital Sovereignty in the Web 2.0 Era What does sovereignty mean for the digital world? We usually talk about Web 2.0 and Web 3.0. Big platforms took away permission from people. In the Web 2.0 revolution, we gave too much power to platforms. Currently, platforms are the representatives of humans on the internet. If you want to do something, you have to go through a platform. We want to change this setup and return to the state of the internet before the big platforms and the Web 2.0 revolution. If you want to talk to somebody, you shouldn’t need a man-in-the-middle or a representative. You could do everything on behalf of yourself; you control your own data and your own compute. To represent yourself in a network, we need some form of identity—a crypto identity—to represent yourself in a secure but anonymous way. The Three Pillars of Digital Sovereignty Digital sovereignty is mainly about ownership: you own your identity, you control it, and you own your data. There are three big pieces to this: * Data Ownership: You own your data and control access to it. * Software Control: You own or control the software that runs on top of your data to make it useful. In terms of AI, this means owning the code or the software around your agent. You should be able to audit it, change it, and adapt it to your needs. * Compute Sovereignty: You need compute to run this software. This is the most challenging part because running powerful models requires heavy computational power, GPUs, and powerful servers. The GPU and Infrastructure Challenge Some people compare access to GPUs to access to power stations. They say you don’t need to run your own power station to consume electricity. However, for electricity, we have laws that protect consumers, multiple suppliers, and better regulation. With LLMs (Large Language Models), we don’t have this. If a player goes out of the market, you are left with “garbage” that doesn’t work anymore. If a provider like OpenAI decides you are “not so good for them” and cuts your access, you lose everything: your conversations and your workflow. The Path to Sovereign AI We need to own the computational power and the models just as we own the data. This opens the question of how to own expensive infrastructure or create a “commodity” for it that a group of people or states could manage. For example, there are initiatives in Switzerland where they are making their own LLMs aligned with the state, with security guardrails acceptable to Switzerland rather than the US, and accessible to all citizens. Hosting the model yourself offers the highest level of privacy because you have a “zero sharing” policy. You ensure your data is not contributing to training models that might discriminate against groups you belong to. The Future: Local and Edge Agents The goal is to own your data, your compute, and the infrastructure. While AI infrastructure is not easily achievable for everyone, “local edge agents” are. * We can use smaller LLMs that run on our own machines. * We can afford servers with a few GPUs to run middle-sized models. * Some agents will run on LLMs, some on distilled SLMs (Small Language Models) for specialized tasks, and some on classical machine learning or neuro-symbolic approaches. These can run not just on powerful machines, but even on a user’s phone. For example, at King, we built an agent that made inferences directly on the user’s device (iPhone or Android). This is a target for private and sovereign AI. If you own your phone, you own the hardware where the agent runs, and you have a full data snapshot of all your conversations. Conclusion Sovereignty matters because nobody can “cut you off”. You own, change, and do anything you want with your system. Furthermore, if you decide to contribute to training a model, you can do so in a fairer way by receiving benefits for providing your data, creating a more equal data economy. Ultimately, sovereignty is about protecting our future from surveillance capitalism and the control and domination of big companies or countries. Get full access to Sovereign Agentic AI (Volodymyrs View) at volodymyrpavlyshyn.substack.com/subscribe (https://volodymyrpavlyshyn.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

12. 

    25 Feb 2026

    Why Agents Need Memory

    Introduction and Experience Hey, we will talk about the agents and why agents need memory, and how it could look like, and why, for example, RAG is not enough and why RAG is not true memory and all of this thing. So, you know, I was working on the memory for the last two years. I was working on it actively when I was the part of the Keen, the privacy-focused AI assistant. Right now, I am working more on the agents and the protocols and agent identity at Affinity, but still memory is my big passion. The Landscape of Agent Memory If you’re following the space right now, we have the huge booming topics like context graphs, decision traces, how to make agents learn from his decisions. We also have some manipulations around this because we dehumanize the agents and actually compare them with the people that could take ad hoc decisions, and actually for me, it’s not really true. Anatomy of an Agent But you know, let’s talk about the agent anatomy first. So majority of the agents that we’re talking about nowadays, unfortunately in a core have the large language models. And large language models have some kind of memory because they have the training data stored in weights, and actually the LLM has something that it is remember, and it remembers a lot. But the problem is that it’s not acquiring new information and it’s not acquiring information, for example, user gives to them or some company specific if we talk about the enterprises. The Rise and Limitations of RAG And then what we do, we build the knowledge base and we apply the RAG, yeah, so augmented generation. And this helped us to bring the data that was not in the data set and allow LLM to work with them. And actually RAG was quite successful and we start from simple vector databases and vector search, then we all realize that it gives us some decent results, works quite well, for example, for the documents, works quite well by the way if we have the limited amount of documents. Because if the amount of information will grow, we will see the decay, and especially when we build the vector space representation of all our documents and we will see if they condense. So if they focus on one topic in one place or they just sparse and distributed. The more condensed they are, the more the errors will get because we do not know which of the chance to choose. Advanced Memory Strategies And then we apply different strategies. It was the boom of graphs, entity recognition, different strategies combining the RAGs with the graph with the vector search for RAG, then combining the graphs with the vector search for RAG and some advanced topics from naive BM25 indexing to some advanced graph neural network indexes and all of the things. And all this helped, but still the accuracy struggle, and we even have the research that it was the broken promise that actually the RAG do not solve the hallucination of the agents, it’s improve a bit. And then we stay with the questions, okay, if not RAG, what we could do to fight with the hallucination from one side, from another side improve the conversation experience. Shifting from Bots to Agents And right now when we shifted from the bots that talk with the users to the agents that do something for the users, we discovered that we have the new properties to the agents that not just needs to maintain the value conversation and pick up the facts that relevant to the conversation. We have much bigger challenges: how the agent could follow the plan, how the agent could execute the tasks without the hallucinations, and how to make his actions align with our goals and wishes. And it’s way more challenging task than just simply correlation of the information chunks that GraphRAG gives us. Mimicking Human Memory So then we end up with the concept of the memory because we trying to mimic the humans and we have the memory. And it’s interesting and deep talk: how human memory works, do we have one memory or we have multiple memories, how it’s organized and how we do the processing. But if we could shortly talk about the memory and why RAG is not memory, the first big thing, especially for the conversational memory, that the RAG doesn’t have the context. The RAG doesn’t have the deep context in episodic context. So we remember something in a context of the emotions and events that happened to us. And we don’t have the emotional context, so we don’t have the emotions at all. Right, we could capture them somehow, but majority of the systems doesn’t have even the notice of this, right? And the human memory, the stronger it is, the stronger the emotion was. And if they’re negative or they’re just dangerous stuff to you, you will remember it much better. I don’t think that it’s a positive of the human memory, but it was the survival mechanism. Episodic Memory and Processing And another one that these events or the information that we remember more focused on the episodic memory. And we even have the episodic buffer. So we have the big chunks that have the episodes, they go to the episodic buffer, then they go to the temporal memory, then in night we just process the memories, move them to the permanent memory, and then we have a couple of cognitive processes that do the semantization of the episodic memory. And episodic memory decay faster, but all our memory, somehow the big chunk of our declarative memory actually is the episodic memory and have the fight episodic context. The Challenge of Time in Memory And unfortunately RAGs struggle with it. Yeah, we could build some graph-based memory systems that have the context concept, that have the episodic concept as event graphs, for example, do. Then we get completely new challenge that we wants to process the episodic memory and now we need the notion of time. And time itself is a huge, huge topic. And actually I wrote a book about the AI memory and time because time deserve itself the book, and maybe two to be honest. So this episodic context go quite tight to the understanding of time, processing time, and actually time is not timestamps. Time actually the sequence or the DAGs, the directed acyclic graphs of the events. And if we’re talking about the human, these events have some different emotions and different impact on our life. They have some consequences, they have the relation, they have the casual relation between each other. And I talking about this architecture of this event-focused, casual, time-aware memory in my book. So it will take a quite long time to describe it here, but if you wants to understand it, you could read my book about conversational memory or you could also find the architecture of this memory in the my new book that I still working on it. https://leanpub.com/time-aware-ai-memory (https://leanpub.com/time-aware-ai-memory) Beyond Context Graphs It’s a book about what’s goes beyond the context graph and how to make the agents actually do what we ask them to do. And another thing that GraphRAG have quite limited capabilities to build the associations and the semantic packages. So we always remember the semantic information in a connection to another semantical concept. That’s why we all like graphs because they somehow mimic how our semantic memory works because our semantic memory is the huge network. But the trick is that our semantic memory, if we read some researches, it’s not the directed graph. It’s more the multi-layered hierarchical network that have at least three kind of hierarchies and some sub-hierarchies and the classification of the things. So you have some mixture of multi-layered graph that form this complex network. But our main ability is to build the associations and build the links between the concepts, and yeah graphs could do it, but GraphRAG even have the quite limited capacities to do it. https://leanpub.com/beyondcontextgraphs (https://leanpub.com/beyondcontextgraphs) Memory as a Cognitive Process And the biggest part that RAG is only one cognitive process, right? That you get the question, you find what’s relevant, you give it back. But human memory have huge amount of cognitive processes: of processing, extracting, memorizing, semantization, the dynamic recall, the decay, and forgetting. And forgetting itself actually is the big topic that we will talk next. But your retrieval happens without the understanding of the information, it’s just some mathematical filtering like BM25 or some graph algorithms that find the centrality of the different entities and all other thing. It’s too naive and it’s not enough. The Role of Forgetting and Recall And I already mentioned that the memory require forgetting and forgetting is a huge, huge topic because our memory is more focused to forget. But it’s still big question how we forget, do we forget forever or we just change the priority and importance of this information and we have struggle to recall it and all of the things. And recall actually have the loop: the more often you recall the information, the better you remember it, you make this neural network stronger and you just remind that it’s something important to you and all other thing. So as you see, the forgetting is tightly connected to recall in a human memory. And actually I also build this naive mechanisms to look in that if we collect the statistic of the retrieval and recall, and if it’s more often then probably it’s something that we wants to put some importance to it. And when we try to form this recall loop with the forgetting, then I proposed the different concepts of attention. Focus, Attention, and Task Orientation So we just remember what’s matter and we remember what’s matter to us in the particular action and task. And actually human memory is quite task-oriented and you quite often recall the things around the actions and by the way, they activate completely different areas of your brain. So you try to recall the information with the purpose to do something. So and your skills is slightly different kind of memory, it’s not declarative memory, and even if you have amnesia, you still know how to drive the bicycle. It’s yet another evolutionary thing, it’s more automatic and it’s quite interesting topic. But then I guess that agent memory could be heavily built around the concept of the focus and attention. And then the forgetting is something that doesn’t matter right now for this particular task. And it’s quite task-oriented. Explanability and Goals And if it’s task-oriented, then we shift from the conversation and conversational relevance to more important thing that the context graph nowadays could solve: how you taking the decision, how to make this decision explainable, and how to make this decision of the agent following your goals, following your constraints, following your company policy and all other thing. And I would say that this kind of context graph and agent memory architecture in a context of the tasks have completely different focus and attention mechanisms from the conversational memory because in conversational memory, you have only one cognitive process that are quite complex, or maybe couple of cognitive processes of digesting and extracting the memories and actually finding the relevant memories according to the conversational context. So it’s simple. Social Dimension of Memory But when we have the agent that actually communicate with other agents and actually cooperate with them and do something, so it’s already social component of the memory that agents needs to remember: who is reliable, to whom the agent could trust, to whom agent could delegate. So we get this social dimension of the memory for the agents. And the most important that agent interact also with the humans that give him the tasks, and maybe some other agents give him the tasks. And it’s open question: should agent differentiate the human and the agent or for agent it’s all the agents and it doesn’t matter if this agent drinks tea while talking or just consume a bit of energy? So it’s a good question that we still needs to get answer. Operational Memory and Symbolic AI But the agent operational memory is more focus on the tasks. It’s more focus on the rules and what could happen and what’s to do if something happens. And then it’s open us the good old space of the symbolic AI and expert system and rule-based memory and rule-based expert system and approaches that we all forget because we heavily failed in eighties with the Prolog formal system and first-order logic and all other things. But right now all this stuff is more and more relevant. Future Directions: Promise Theory And what’s more important that rules relevant, we needs to have the memory to remember the rules, we needs to have the reasoning capabilities and solvers that could apply the rules and what’s more important, we just needs to have some framework that actually apply all this rule-based systems to the agent interactions and agent intents and all other thing. And I touch this topic in my new book, What Goes Beyond the Context Graphs, and today we have the memory for sure that we already have a chance to talk. And we have the concept of the promises and Promise Theory of Mark Burgess. And in Promise Theory, we form some kind of promise graphs. And these promise graphs actually captures not just the decisions but some interaction of the agent with other agents, some interactions of the agent with the tools and data information. So we have some promises of the interaction of the agent with the memory, we have some promises that interact with the tools. So somehow we have quite complex audit log that could be reflected, could capture what agents made, what other agents made for the agent, what kind of data traces we have, and all this complex promises could lead us with the casual analysis to the final decisions, give us the possibility to apply the rules and have some kind of explainability and causality. Conclusion So the combination of causality analysis, data traces, and actually the Promise Theory give us the good foundational framework to go beyond the context graphs because the context graph right now quite weak concept that say that we needs to store the decisions but we have no implementation of this. And actually I also talking about the semantic space-time that could be used for this. So please, I have the bundle for the memory that explain all the things in two books, one is time-focused, another one I work on this beyond concepts. So if you’re keen to learn about the memory more, if you’re keen to build the agents that remember and do what you ask them to do, just read my books, contact with me, and let’s talk together about this complex topic. To read my memory book bundle : https://leanpub.com/b/agenticmemory (https://leanpub.com/b/agenticmemory) Get full access to Sovereign Agentic AI (Volodymyrs View) at volodymyrpavlyshyn.substack.com/subscribe (https://volodymyrpavlyshyn.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

13. 

    18 Feb 2026

    Ways of Working with AI: Why Leaving the Flow Matters

    Why We Need to Leave the Flow We live in a culture obsessed with entering the flow state. There is no shortage of focus music, productivity rituals, and concentration hacks—most of which, by the way, don’t work the way their creators promise. The brain does operate on specific electrical frequencies: alpha waves around 8–12 Hz associated with relaxed alertness, theta waves around 4–8 Hz linked to creative insight, and the famous gamma bursts around 40 Hz that accompany moments of cognitive integration. The problem is that most streaming audio formats and their compression artifacts destroy exactly those frequencies. Binaural beats require uncompressed audio delivered through headphones; what you find on most platforms is a degraded approximation that produces no measurable effect. So don’t waste your focus on the focus tools. That is already a kind of irony worth sitting with. But even setting that aside, the deeper issue is that we have been optimizing for the wrong thing entirely. We have been asking: how do I get into flow? when the more important question is: when do I need to leave it? The goal is not to stay in flow as long as possible. Flow is cognitively expensive. When the brain is in a state of deep focused attention, the prefrontal cortex—the region responsible for planning, decision-making, and working memory—is running at high intensity. It is drawing on glucose at an elevated rate. Studies using fMRI and PET imaging have shown that sustained cognitive effort depletes local glucose availability in prefrontal circuits, and that performance degradation follows closely behind. This is not metaphorical tiredness. It is a measurable biochemical process: the longer you push, the more literally fuel-starved the most important parts of your thinking brain become. Prolonged, unbroken focus also creates what psychologists call attentional narrowing—a tunnel vision effect where the brain increasingly filters out peripheral information in order to maintain concentration on the primary task. This is useful for execution. It is terrible for problem-solving. The brain stops noticing weak signals, anomalies, and the unexpected connections that are often the source of the most valuable ideas. You go deeper and deeper into what you already understand, while the edges of the problem—where the interesting stuff lives—fade out of view. Then there is the question of burnout. The word gets used loosely, but in its neurological sense, burnout represents a chronic dysregulation of the stress response system. The hypothalamic-pituitary-adrenal axis, which governs how the brain and body respond to cognitive and emotional demands, requires recovery periods to recalibrate. When those periods are denied—when every hour of the day is filled with high-stakes cognitive load—the system gradually loses its ability to modulate itself. Cortisol levels that should drop during rest remain elevated. The dopaminergic motivation system, which depends on cycles of anticipation, effort, and reward, starts to flatten. The ability to feel engaged or rewarded by work diminishes, even when the work is genuinely meaningful. Paradoxically, the harder it becomes to re-enter focus after an exhausting deep work session than after a session interrupted by real breaks. The brain needs transition time. Leaving the flow is not a weakness or an interruption. It is part of the architecture of sustained high performance. How Flow Works Differently with AI Tools The introduction of AI tools has not simply made us faster—it has structurally changed the nature of flow itself, and most people have not yet noticed what was lost in the change. Before AI-assisted workflows, a session of focused work meant synthesis and creation: you were the one producing, making decisions, wrestling with ambiguity, and watching results accumulate through your own effort. That loop had a natural rhythm and a natural ceiling. You could only write so fast, code so fast, design so fast. The pace of output was calibrated, roughly, to the pace of human cognition. With AI tools, the pace of output accelerates by an order of magnitude. The system can generate in seconds what would have taken hours. This feels like an unambiguous good, and in many respects it is. But it creates an immediate and deeply underappreciated consequence: an equally enormous volume of work for reviewing that output. The tools don’t reduce the cognitive load. They shift it, compress it, and in many cases amplify it in ways that are less visible and harder to manage. There is also something more subtle happening. When you produce work slowly, you are continuously embedded in the thinking that generates it. You understand why each part exists. You have context for every decision. When AI generates work quickly and you review it, you are arriving late to a process you did not fully participate in. The cognitive overhead of reconstruction—of rebuilding the reasoning behind something you did not create—is significant and often invisible. You think you are just checking. You are actually doing a form of reverse engineering, and the brain is paying the full cost of it. Changed Role: From Creator to Reviewer The Broken Dopamine Loop One of the most significant shifts in AI-assisted work is the change in the reward architecture of what you do every day. This matters more than most productivity discussions acknowledge, because dopamine is not just the molecule of pleasure—it is the molecule of motivation, learning, and directed behavior. Here is how the system works in brief: when you engage in goal-directed behavior and achieve a result, the ventral tegmental area of the brain releases dopamine into the nucleus accumbens and the prefrontal cortex. This release does two things. It produces the feeling of satisfaction and accomplishment—the intrinsic reward of work done well. And it strengthens the neural pathways associated with the behavior that produced the result, making you more likely to engage in similar behavior in the future. This is the basic engine of motivation. It is how skills get built, habits get formed, and people develop what is sometimes called a love for their craft. Crucially, dopamine is not only released on completion. Research by Wolfram Schultz and others has shown that the dopaminergic system is highly sensitive to prediction and progress—to the anticipation of reward and the incremental signs that you are moving toward it. This is why making things is so satisfying even while it is happening, not just when it is done. Every small indication of progress—a function that works, a paragraph that lands right, a design element that clicks into place—triggers a small dopamine response. These micro-rewards stack up across a session and are part of what sustains engagement over long periods of focused work. When you transition to guiding an AI—setting tasks, reviewing outputs, correcting direction—roughly 80% of your time becomes evaluation rather than creation. The sense of authorship is diluted. The feedback loop between effort and result that the dopaminergic system depends on is interrupted. You are not building; you are managing. The intermediate rewards that used to punctuate the creative process are largely gone. And the brain notices the difference in a very literal sense, even when you don’t consciously acknowledge it. Over time, this changes not just how you feel during work but how motivated you are to begin it. The anticipatory dopamine that gets you to sit down and start—the excitement of engaging with a problem—depends on a learned association between effort and reward. When that association is weakened by months of reviewing rather than creating, the motivation system starts to stall. Tasks feel heavier. Procrastination increases. What looks from the outside like laziness or disengagement is often the rational response of a reward system that has been starved of the inputs it needs. Review as Micro-Decision Fatigue Here is the paradox that most people working with AI tools discover without being able to name it: reviewing feels less effortful than creating, but it is frequently more exhausting. The explanation lies in what cognitive scientists call ego depletion—the observation, supported by decades of research and most robustly theorized by Roy Baumeister, that the capacity for self-regulation and decision-making draws on a limited resource that depletes with use. Every decision you make, regardless of its size, draws down that resource. The brain does not distinguish between a high-stakes strategic decision and a low-stakes micro-judgment about whether a generated sentence is acceptable. Both cost something. When you review AI-generated work, you are making decisions constantly. Is this correct? Is this accurate? Does this match the intended tone? Should I accept this or rewrite it? Is this error significant or cosmetic? Each one is small. But they accumulate. A single review session might involve hundreds of these micro-decisions, each one drawing on the same prefrontal resource pool that governs concentration, impulse control, and emotional regulation. The result is a specific kind of fatigue that is easy to misread: tired without having made anything, depleted without the satisfaction of output. Your glucose is low but your creative tank feels empty too, because you never filled it. The decision-making cost was paid, but none of the reward signals that usually accompany it arrived. This is a particularly fertile environment for burnout—and for the subtle degradation of work quality that comes before you even recognize you are burned out. There is another dimension worth naming. The kind of decision-making involved in review is largely inhibitory: you are constantly evaluating what to reject, what to correct, what to constrain. The prefrontal cortex is working in a mode of critique rather than generation. This is neurologically different from creative production. Generation draws on wider associative networks, on the default mode network’s capacity for spontaneous thought, on the interplay between focused and diffuse cognition. Critique is narrower, more analytical, more tiring per unit of time. Spending most of your working day in inhibitory evaluation mode is, in a neurological sense, structurally different from spending it in generative mode—and the difference in how it feels at the end of the day reflects that. Diffuse Thinking: The Mode We Keep Skipping There are two fundamental modes of cognition that neuroscience has documented with increasing clarity over the past two decades. The focused mode is the deliberate, analytical, goal-directed state we optimize for. It is associated with activation of the prefrontal cortex, the sustained attention networks, and the suppression of the default mode network. This is the mode we mean when we talk about flow, concentration, and deep work. The diffuse mode is something different: the background processing state the brain enters when it is not locked onto a specific task. It is associated with activation of the default mode network—a set of regions including the medial prefrontal cortex, the posterior cingulate cortex, and the angular gyrus—that was once dismissed as the brain “idling” but is now understood to be doing some of the most important work cognition requires. During diffuse mode activity, the brain consolidates recent learning, integrates information across domains, runs simulations and hypotheticals, and makes the unexpected associative connections that are the substrate of creative insight. You cannot be in both modes simultaneously. They are, to a significant degree, mutually inhibitory—the attentional networks and the default mode network suppress each other. This means that every hour the brain spends in focused mode is an hour it is not spending in diffuse mode. For short periods, that trade-off is entirely worth it. Extended over an entire working day with no real breaks, it means the brain never gets the processing time it needs to do its most integrative work. This is not a new problem, but AI tools have made it worse in a specific way. The volume and pace of AI-assisted work can fill the entire cognitive day. Where previous workflows had natural pauses—waiting for code to compile, waiting for feedback, walking between meetings, the slow transition between tasks—AI-assisted workflows tend to eliminate those gaps. There is always more to review. There is always another output to evaluate. The pace that the tools enable can become a pace that never allows the brain to shift modes. The implications accumulate over time. The creative insight that should have emerged during a walk, during ten minutes of unstructured thinking, during the transition between tasks—never arrives. The synthesis that should have connected last week’s problem to this week’s challenge doesn’t happen because there was no diffuse processing period in which it could form. The longer the pattern continues, the more impoverished ideation becomes, and the more the work narrows to execution and review rather than genuine invention. Protecting time for diffuse thinking is not laziness. It is not a luxury for people with too much time. It is cognitive hygiene in the same way that sleep is physiological hygiene—not optional maintenance but a structural requirement of the system. The Think-First Pattern and the Space for Creativity Given all of this, what does a healthier way of working with AI actually look like? There is no single answer, but one of the most useful reframes is what might be called the think-first pattern. The pattern is simple: when a new challenge, problem, or creative task arrives, resist the impulse to immediately delegate it to an AI. Instead, hold it. Sit with it for some period—it might be five minutes, it might be a day, depending on the complexity. Sketch. Think. Let the problem develop partially in your own mind, with your own understanding of its shape and difficulty and interesting dimensions. Let your default mode network work on it during the background processing periods that happen between focused sessions. Only then bring in the AI as an amplifier of thinking that is already underway, rather than as a replacement for the thinking itself. This is not a productivity hack. It is a way of preserving the cognitive engagement with problems that makes work meaningful and that keeps the motivation system functioning. When you arrive at an AI tool already having thought seriously about a problem, you are in a fundamentally different relationship with the output it generates. You have a basis for evaluating it that is richer than surface pattern-matching. You have opinions. You have a sense of what the interesting edges of the problem are. You are genuinely authoring the direction rather than ratifying a direction the system has already chosen. This also preserves the dopamine architecture of creative work. When the AI is amplifying your thinking rather than replacing it, the reward signals still fire. You still experience the satisfaction of seeing your ideas take form. The intermediate feedback loop—effort, progress, reward—remains intact because you are genuinely part of the generative process. There is a useful analogy in how experienced writers approach research. The temptation is to research exhaustively before writing—to accumulate everything that might be relevant and then begin. But many writers find that writing a rough draft first, even an incomplete and uncertain one, and then using research to verify and deepen it, produces better work. The act of writing first forces you to articulate what you actually think, to locate the gaps and uncertainties in your own understanding, and to engage with the material as a participant rather than a consumer. Research that follows thinking is more productive than research that precedes it, because you know what questions you are actually asking. The think-first pattern applies the same logic to AI tools. Use the AI after you have thought, not instead of thinking. The space you create for your own cognition before engaging the tools is not inefficiency. It is the part of the work that makes everything else better. AI tools are genuinely powerful, and working with them thoughtfully is a real skill worth developing. But the skill is not just technical—it is neurological and behavioral. It requires understanding what the brain needs, not just what the tools can do. Change your working habits deliberately. Build recovery time into your workflow the same way you schedule tasks. Find new anchors for the dopamine cycle, intentional moments of creation and completion that are fully yours. And protect, with some care and some discipline, the space where your most valuable thinking happens—the slow, wandering, uncertain, generative part that no tool can do for you, and that is still, in the end, where the interesting work comes from. Get full access to Sovereign Agentic AI (Volodymyrs View) at volodymyrpavlyshyn.substack.com/subscribe (https://volodymyrpavlyshyn.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

Contact Sovereign Agentic AI (Volodymyrs View) Podcast

Guest appearances

Does not typically book guests

Based on episode analysis; this does not confirm that the show is currently accepting guests.