Sovereign Agentic AI (Volodymyrs View) Podcast

Volodymyr Pavlyshyn

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

  1. 5d ago

    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. 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. 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 * World Models for AI Agents And the rest of my work on agentic memory, knowledge graphs, and edge AI lives here: 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

    10 min

  2. May 27

    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–20

    15 min

  3. May 13

    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 Get full access to Sovereign Agentic AI (Volodymyrs View) at volodymyrpavlyshyn.substack.com/subscribe

    9 min

  4. May 6

    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. 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 s

    16 min

  5. Apr 23

    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

    13 min

  6. Apr 8

    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

    13 min

  7. Apr 1

    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 Get full access to Sovereign Agentic AI (Volodymyrs View) at volodymyrpavlyshyn.substack.com/subscribe

    17 min

  8. Mar 25

    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 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 tri

    17 min
See All (13)

About

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

Information