Sovereign Agentic AI (Volodymyrs View) Podcast

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]

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]

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]

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]

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]