Wednesday, April 15, 2026

Company Revolution: Reshaping Human Collaboration

 
In March 2026, a man named Matthew Gallagher sparked widespread attention across the tech community. In September 2024, he launched Medvi—a GLP-1 telehealth company—with just 20,000.Without hiring a single employee, Medvi achieved 401 million in revenue and a 16.2% net profit margin in 2025. In stark contrast, its competitor Hims & Hers has over 2,400 employees and a net margin of merely 5.5%.20,000.Withouthiringasingleemployee,MedviachievedThat same month, Shenzhen unveiled its "AI Solo-Company Entrepreneurship Ecosystem Action Plan (2026-2027)", aiming to build over 10 "Solo-Company Communities" and incubate more than 1,000 high-growth AI startups by the end of 2027. Early in 2024, Sam Altman predicted the rise of the "one-person unicorn," an outcome Dario Amodei assigned a 70% to 80% probability of materializing by 2026. Medvi seems to have fulfilled this prophecy ahead of schedule.

Together, these events bring an old, fundamental question back into the spotlight: Why do firms exist at all?


The Ghost of Coase

In 1937, a 27-year-old Ronald Coase posed a seemingly simple question in his seminal paper, The Nature of the Firm: If the market mechanism is so efficient, why do we need organizations like firms?

His answer was equally concise: Transaction costs.

Getting anything done in the open market requires searching for information, negotiating prices, drafting contracts, monitoring execution, and handling breaches. When combined, these frictions are sometimes far more expensive than bringing people together under a single organization and coordinating them through a hierarchy. The boundary of a firm is drawn exactly at the line where internal coordination costs equal external transaction costs.

This framework dominated organizational theory for nearly a century. During the internet boom, some declared Coase obsolete—arguing that as information transparency soared and search costs plummeted, outsourcing and the platform economy would cause companies to shrink.

They didn't. Over the past two decades, tech giants have only grown more massive. Google employs 180,000 people, Meta 70,000, and Amazon once surpassed 1.5 million. While the internet lowered certain transaction costs, it simultaneously created new coordination demands—data governance, algorithm tuning, ecosystem maintenance—activities that were far more efficient to manage internally than on the open market. The ghost of Coase had not dispersed.

But AI—specifically the agentic technologies that have matured since 2025—is accomplishing what the internet could not: It is compressing both transaction costs and internal coordination costs simultaneously.

This is the true paradigm shift.


The Simultaneous Collapse of Two Cost Curves

Let’s look at transaction costs first.

The traditional friction points of external collaboration—sourcing talent, evaluating capability, communicating requirements, and reviewing deliverables—are being completely rewired by AI. Need a product illustration? You used to have to find a designer, brief them, wait for a draft, request three rounds of revisions, and process a payment. Today, Midjourney and ten minutes of prompt iteration get the job done. Need a legal contract template? For highly standardized scenarios, Claude can generate a viable draft in thirty seconds. Need a landing page? Cursor, coupled with a few descriptive sentences, can have it live in half an hour.

This isn't an incremental improvement in efficiency; it’s an order-of-magnitude collapse. When external transaction costs shrink from "days" to "minutes," work that previously had to be done in-house can suddenly be executed in the open market at near-zero friction.

Now, consider internal coordination costs.

In a 500-person company, how many layers must a CEO's decision pass through before it becomes frontline execution? Every intermediate layer consumes information, introduces latency, and creates drift. Meetings, weekly reports, OKR alignments, cross-departmental syncs—these activities, which generate no direct value, can consume 40% or more of the working hours in large enterprises.

AI agents are not replacing specific roles; they are replacing coordination itself. When a founder can issue instructions in natural language directly to an AI, and the AI autonomously breaks down the task, invokes tools, and delivers the result—the core function of middle management is hollowed out. This isn't because middle managers aren't working hard; it's because their function as information routers and task dispatchers is being superseded by a vastly more efficient mechanism.

With both curves collapsing simultaneously, the solution to Coase's equation fundamentally changes: The optimal boundary of the firm is rapidly retreating.


Not a "Small Company," but a New Species

However, framing this shift merely as "companies getting smaller" completely misses the depth of the transformation.

Medvi is not a small company. Based on its current growth trajectory, its annualized revenue is approaching $1.8 billion. Nor is it a "lean team" in the traditional sense—Gallagher didn't outsource the work to a handpicked army of freelancers. He utilized a full-stack automation system comprised of over a dozen AI tools. ChatGPT, Claude, and Grok handle code and copy; Midjourney and Runway generate ad creatives; ElevenLabs manages voice interactions with customers; and custom AI agents orchestrate the various systems. True, GLP-1 telehealth is a highly standardized sector naturally suited for automation, and Medvi's exact model may not be universally replicable. But it proves one undeniable fact: A single human, augmented by an AI system, can sustain a business scale previously unimaginable.

This isn't just "small"—it's an entirely new organizational topology.

A traditional company is a hierarchical network composed of human nodes. Information flows from the bottom up, decisions cascade from the top down, and processes and culture act as buffers against signal loss. This architecture scales by adding people—more nodes, deeper layers, and more complex procedures.

An AI-native company closely resembles a star network with the founder at the absolute center. The founder is the sole human decision node, surrounded by specialized AI agents. It scales not by adding headcount, but by adding compute and tooling. Its organizational "width" can be immense—handling marketing, product engineering, customer service, and finance simultaneously—but its "depth" is extraordinarily shallow, with a decision chain that is practically non-existent.

The difference between these two architectures isn't one of degree, but of paradigm. It’s akin to the difference between single-celled and multi-celled organisms—it’s not merely about size, but a fundamental divergence in organizing principles.

And this new species is already beginning to branch into distinct subspecies.


Three Emerging Forms

Based on current real-world models, we can observe three primary forms taking shape.

Type 1: The Super Individual Company. Medvi is the archetypal example. One person, equipped with an AI toolchain, covering the entire lifecycle from product development to customer acquisition and delivery. Its core advantage is decision velocity—no hierarchies, no meetings, no office politics. The founder's judgment translates directly into action. Its disadvantages are equally stark: It is hard-capped by the founder's cognitive boundaries and energy, and it is inherently limited in scenarios requiring deep interpersonal trust (like enterprise software sales or government relations).

Type 2: The Human-Machine Hybrid Team. A core team of 3 to 10 people, each paired with multiple AI agents, projecting a capability far exceeding their headcount. This model is already prevalent in independent software development, content creation, and consulting. It preserves the flexibility and creativity of human collaboration while leveraging AI to exponentially amplify output. A study by the UC Berkeley School of Information noted that such AI-native organizations are "network structures rather than hierarchies—defined by API connections instead of org charts, and scaled by adding compute rather than headcount."

Type 3: The Pulse Organization. This is the most radical and imaginative form. It forms temporarily around a specific objective and dissolves upon completion. Founders, AI agents, external vendors, and freelancers assemble into a highly efficient execution unit within days, deliver the outcome, and disband. There are no permanent employment contracts, no offices, and sometimes not even a registered legal entity. The entire "company" exists as a set of API calls and smart contracts. Anyone can spin up a "temporary firm" of hundreds of agents as effortlessly as ordering takeout, and dissolve it just as quickly.

These three forms are not mutually exclusive but exist along a spectrum. The choice depends on business complexity, trust requirements, and regulatory environments.


Large Corporations Won't Disappear

A common cognitive trap is assuming that if AI allows small teams to do the work of large corporations, enterprise giants are destined for obsolescence.

They are not. The other half of Coase's framework still holds—there are certain transaction costs that AI simply cannot eliminate.

Scaling hardware manufacturing requires supply chain integration. Pharmaceutical R&D demands long-cycle capital investment and regulatory compliance. Financial services necessitate licenses and credit backing. Defense and infrastructure involve sovereign security. The "transaction costs" in these domains are not just about information and coordination; they involve trust, compliance, capital, and physical assets—frictions that AI is far less equipped to remove than informational ones.

More importantly, massive corporations are weaponizing AI as a moat. Microsoft has armed its entire Office suite with Copilot; Google has woven Gemini into everything from search to cloud infrastructure. These behemoths are not fighting the decentralization brought by AI; they are using AI to aggressively fortify their economies of scale—doing significantly more with fewer people while maintaining organizational integrity.

What is actually happening is not the death of the giant corporation, but the collapse of the middle ground. The companies that are neither large enough to command economies of scale nor small enough to enjoy AI-driven agility—mid-sized enterprises with tens or hundreds of employees, relying on labor-intensive services for profit—will face the heaviest existential pressure. They can neither pivot iteratively like a Super Individual nor erect the ecosystem moats of a tech giant. Where the displaced workforce from this squeezed middle echelon will go may become the most profound social challenge of this revolution.


From "Hiring People" to "Orchestrating Agents"

If the essence of a company is a coordination mechanism, the core shift in the AI era is this: The object of coordination has transitioned from humans to agents.

The central tenets of traditional management—incentive design, culture building, talent acquisition, performance reviews—revolve entirely around "how to get a group of humans to collaborate efficiently." When the primary subjects of collaboration change from organic employees to AI agents, the very definition of management changes. You don’t need to pay an AI a bonus, organize team-building retreats, or navigate office politics. But you do need to master something else entirely: Workflow design.

Selecting the right AI tools, defining the data flow between them, determining where to inject human judgment, monitoring output quality, and handling edge-case anomalies—these activities constitute a brand-new "management" paradigm. It’s akin to orchestrating a distributed computing system rather than leading a human team.

This necessitates a fundamental pivot in the skill sets required of founders and executives. In the past, a great CEO excelled at reading people, motivating teams, and cultivating culture. Today—and definitively in the future—a great AI-native founder must excel at understanding AI capability boundaries, designing highly efficient human-machine workflows, and executing decisive judgment in the critical gaps where AI cannot reach.

To use an imperfect but highly intuitive metaphor: A traditional CEO is like an orchestra conductor, synchronizing dozens or hundreds of musicians. The founder of an AI-native company is a music producer in a studio, sitting alone at a workstation, using synthesizers and samplers to craft a complete album single-handedly.


In 1937, Coase answered the question of "why firms exist." Eighty-nine years later, AI is providing an amended answer: Firms still exist because coordination still incurs a cost—but the answers to "what we coordinate" and "how we coordinate it" have fundamentally changed.

As the object of coordination shifts from humans to agents, optimal business scale, organizational structures, and competitive logic are all being reshuffled. We are only in the very early innings of this Great Reshuffling—Medvi is merely the first visible prototype, not the end state.

Over the next few years, the most critical question won't be headline-grabbing curiosities like "Can a one-person company reach a billion dollars?" The deeper, far more consequential shift is this: As transaction costs and coordination costs crash simultaneously, how will the fundamental structures of human collaboration—from corporate governance and labor relations to the social contract itself—be systematically rewritten, layer by layer?

That is the question the ghost of Coase is truly compelling us to answer.

Sunday, April 05, 2026

The Infrastructure War of the Agent Era: Why Every Big Tech Company Is Building a "Memory Layer"

 On March 24, Oracle unveiled a product at its AI World Tour that sounded routine but carried far-reaching implications: Oracle AI Agent Memory—a unified memory core built directly into the database engine, designed specifically for AI agents.

That same week, Microsoft quietly updated its Azure AI Foundry reference architecture. The only material change: a new "user-level persistent memory layer" backed by Cosmos DB, with per-user isolation via Entra ID.

Two weeks earlier, Mem0—a startup whose entire existence revolves around "AI memory"—announced it had become the exclusive memory provider for the AWS Agent SDK. The company has nearly 50,000 stars on GitHub and had just closed a $24.5 million Series A.

Taken individually, none of these are headline news. Stack them together, though, and the signal is unmistakable: the memory layer is graduating from an "auxiliary feature" of agents into a standalone piece of infrastructure.

If you've lived through the arc from Web 1.0 to cloud computing, this scene should feel simultaneously foreign and familiar. The last time the industry fought this hard over who gets to define a "storage layer" was around 2005—the year Amazon launched S3 and SimpleDB, Google published the Bigtable paper, and the world suddenly realized that the database was no longer just a component of an application. It was the foundation of the entire internet.

Twenty years later, the same script is playing out in the age of agents. Only this time, what's being stored isn't user data. It's an agent's memory.


From "Amnesia" to "Memory Architecture"

Back in January, I wrote two pieces on AI memory. The first examined the context-management dilemma of large language models—million-token context windows sound impressive, but the "lost in the middle" effect, context rot, and attention dilution make them far less reliable than the headline numbers suggest. The second shifted the lens to the enterprise, dissecting three ticking time bombs buried in agent memory systems: memory poisoning, privilege creep, and tool abuse.

When I finished those articles, the industry's go-to solution was still the cobbled-together "vector database + RAG" architecture—treat memory as a data source for retrieval-augmented generation, use embedding search as a rough stand-in for real memory management. It worked, but just barely.

Three months later, the landscape has shifted.

This isn't incremental change. It's a phase transition. A new product category is crystallizing, and it has its own name: the Memory Layer. Not a plug-in for your database. Not a node in your RAG pipeline. A freestanding infrastructure tier with its own API, its own governance model, and its own commercial logic.

The implications of this shift are probably deeper than most people realize.


Ghosts of Databases Past

To understand why the memory layer matters, the best approach isn't to stare at AI. It's to look backward at the history of databases.

In 1970, Edgar Codd published a paper at IBM that changed the course of computer science: A Relational Model of Data for Large Shared Data Banks. Before that paper, applications manipulated the file system directly to store data. Every program had its own data format. Access control, consistency guarantees, and concurrency management were all hand-rolled by developers. This approach was barely tolerable at small scale; as data volumes and user counts grew, systems inevitably descended into chaos.

Codd's insight was this: decouple the storage and management of data from application logic, and hand it off to an independent system with rigorous mathematical foundations. That was the relational database. It defined schemas for data, ACID properties for transactions, and granular access control. Applications no longer had to worry about how data was stored, locked, or recovered—the database engine handled all of it.

Every layer of software engineering built over the following half-century rests on that abstraction. From Oracle and DB2 to MySQL and PostgreSQL, then on to MongoDB, Redis, and Cassandra—the technology has turned over countless times, but the core separation Codd defined has never changed: the application layer owns business logic; the data layer owns persistence and governance.

Now look at the agent memory ecosystem in early 2026, and you'll see an eerie symmetry: we are in the era before the Codd paper.

How do today's agents manage memory? Most frameworks let agents directly manipulate a vector database—deciding on their own what to store, what to retrieve, and what to delete. Memory has no standard schema. Access control amounts to a line in the system prompt that says "please don't leak other users' information." Consistency guarantees are effectively zero. Forgetting mechanisms are either nonexistent or a blunt TTL expiration.

How is that any different from 1960s applications directly manipulating the file system?

It isn't.


ACID for Memory

Map each core concept of database theory onto agent memory, and every mapping points to an unsolved engineering problem.

Schema. The bedrock of a relational database is a strict schema definition—every row's fields, types, and constraints are declared in advance. Most agent memories today, by contrast, are unstructured text blobs. Is a given memory a fact or a conjecture? Did it originate from user input or tool output? What's its confidence score? When does it expire? In most systems, these metadata are simply missing. Cognee—a Berlin startup that just raised a $7.5 million seed round—is betting on exactly this: building enterprise-grade structured schemas for AI memory so that every piece of it carries auditable metadata.

Access Control. Row-level security in databases has been a mature technology for decades. In agent memory, however, isolation boundaries remain blurry. I used an example in my second article: an agent handles the CFO's IPO financial data on Monday and helps an intern write a weekly report on Tuesday. If they share the same memory pool with no row-level isolation, data leakage isn't a risk—it's a certainty. Microsoft's per-user memory isolation via Entra ID in Azure AI Foundry, and Oracle's implementation of a memory permission matrix inside the database engine itself, both point to the same realization among the giants: access control for agent memory can't live in the application layer. It must be enforced at the infrastructure layer. Just as you wouldn't hand-code SQL injection prevention in your business logic—that's the database's job.

Consistency. What happens when multiple agents read from and write to the same memory store simultaneously? One agent updates a customer's preferences while another is still making recommendations based on the stale version—a textbook read-write conflict. Databases have solved this family of problems with transactions and locking mechanisms for fifty years. In agent memory, the field is nearly a blank slate. Zep's Graphiti engine uses a temporal knowledge graph to track the change history of facts—each memory isn't a static node but a timestamped event stream. It's the most serious attempt at "memory consistency" that I've seen so far.

Garbage Collection. Databases have TTLs, archival policies, and hot-cold tiering. Agent memory needs a "forgetting mechanism"—not everything should be preserved indefinitely. Expired meeting notes, completed task contexts, and corrected misjudgments should all have explicit lifecycle management. This isn't just an engineering efficiency issue; it's a compliance issue—GDPR's "right to be forgotten" applies equally to personal data stored in AI memory. Letta has an interesting approach: it borrows the operating system's tiered memory model and lets agents autonomously manage which memories stay in the "workspace" (analogous to RAM), which go into the "archive" (analogous to disk), and which are permanently deleted.

Put these four dimensions together and you've described the core capabilities a "memory database" should possess. Today, no single product delivers all of them.


Three Bets

The battle for memory infrastructure is currently being fought along three distinctly different lines.

Bet One: Grow Upward from the Database. Oracle's strategy is the most direct—if memory is fundamentally a database problem, then embed memory capabilities straight into the database engine. Oracle Database 26ai unifies vector search, graph queries, relational queries, and JSON document storage within a single engine, then layers an agent memory SDK on top. The advantage: the enterprise's existing data governance apparatus—auditing, compliance, backup, disaster recovery—can be reused wholesale.

Bet Two: Grow Downward from the Agent Framework. Letta's approach is to make memory management a core capability of the agent runtime itself. Agents don't read and write memory through an external API; they manipulate memory directly within their own "thought process"—the way human memory doesn't require opening a separate application to store things; it's part of thinking itself. This is developer-friendly: an agent's memory behavior can be observed and debugged through tool calls. The challenge is scale. When you have tens of thousands of agent instances, each autonomously managing its own memory, how do you guarantee global consistency and auditability?

Bet Three: Build an Independent Memory Middleware. This is the path Mem0 and Zep have taken. They aren't tied to any specific agent framework or database; instead, they offer a standalone memory layer—agents plug in upstream, storage backends plug in downstream. Mem0's designation as the exclusive memory provider for the AWS Agent SDK signals that this "middleware" model is gaining cloud-vendor endorsement. Its strength is flexibility and focus; its weakness is introducing a new dependency and a new point of failure.

The tension between these three approaches mirrors almost exactly the landscape when the NoSQL movement erupted twenty years ago—some said everything should run on relational databases, others insisted document stores were the future, still others claimed key-value stores would solve everything. The actual outcome: different scenarios called for different solutions, but the underlying abstract interfaces converged.

Agent memory layers will very likely follow the same trajectory.


The Invisible Land Grab

Why are Oracle, Microsoft, and AWS stepping into the ring to build agent memory themselves?

Because the strategic value of owning the memory layer may be higher than most people imagine.

In the traditional software ecosystem, the database is the stickiest piece of infrastructure. Enterprise migration costs are punishing—data formats, stored procedures, indexing strategies, and backup architectures all become deeply coupled. It's precisely this stickiness that has allowed database vendors to build commercial empires spanning decades.

The agent memory layer has the potential to replicate that stickiness—and possibly exceed it.

Here's why: an agent's memory isn't a static data table. It's a dynamically accumulated body of experience and judgment. An enterprise-grade agent that has been running for six months doesn't just carry facts in its memory store (e.g., Client A's contract value). It carries contextual associations (the emotional cadence of Client A's last complaint and the resolution that worked), behavioral patterns (checking the knowledge base before consulting a supervisor yields the best results for this ticket type), and even semi-tacit "intuitions" (risk-judgment tendencies formed from historical data).

Migrating this kind of knowledge is an order of magnitude harder than migrating structured data. You can't just export a CSV and call it done.

In other words, whoever controls the agent's memory layer controls the gravitational center of the agent ecosystem.

This also explains why Interloom—a Munich-based startup—was able to raise €14.2 million at the seed stage. What they're doing is striking: rather than providing agents with general-purpose memory, they specialize in capturing enterprise employees' tacit knowledge and converting it into persistent, agent-consumable memory. This hits a real pain point. An MBC Partners research report found that today's AI agents can, on average, access only 30% of an enterprise's knowledge base. The remaining 70%—SOPs, experiential judgment, handling conventions—lives in employees' heads and has never been digitized.

That 70% of tacit knowledge is the unmined gold reserve of agent memory.


Memory Is Identity

Beyond the technology and the business models, the rise of the memory layer points to a deeper question.

Traditional databases store "facts"—who bought what, when they bought it, how much they paid. This data is objective, interchangeable, and identity-agnostic. Swap out the database engine and the data is still the same data.

Agent memory is different. An agent's memory—what it has experienced, what it has learned from its mistakes, the coping strategies it has developed for different situations—these things, taken together, constitute the agent's unique "personality." Two agents running on the exact same foundation model, if they've accumulated different memories in different environments, will behave in fundamentally different ways.

Memory isn't just data. Memory is identity.

This makes the governance of the memory layer extraordinarily complex. When an enterprise decides to switch agent vendors, should the memory migrate with the agent? If the memory contains "judgment patterns" formed from the enterprise's proprietary data, is that the enterprise's asset or the agent vendor's asset? When an agent makes a wrong decision because its memory was poisoned, who is liable—the memory-layer provider, the agent framework, or the user who supplied the input?

None of these questions have answers today. But they'll become urgently pressing within the next two to three years—just as data privacy was ignored for a decade before GDPR, until it suddenly became the number-one priority for every tech company on the planet.


A New Layer in the Stack

Back to the three news items from the top.

Oracle, Microsoft, and AWS all moving on agent memory in the same window isn't a coincidence. It marks the emergence of a new architectural consensus:

The model layer owns intelligence. The memory layer owns experience. The harness layer owns reliability.

If 2024 was the arms race for model capability and 2025 was the cost war over inference efficiency, then 2026's emerging battlefront is the fight over memory infrastructure standards.

The winner of this fight won't necessarily be whoever has the best technology—history has proven that much. What decides the outcome isn't the technology itself but the toolchain, developer community, enterprise certifications, and migration costs that coalesce around it.

The competition for the agent memory layer will follow the same playbook.

And for everyday developers and enterprise decision-makers, the single most worthwhile thing to do right now may not be to rush into picking a memory solution. Instead, take a hard look at your own agent systems: What is your agent actually remembering? Where are those memories stored? Who can see them? And when should they be forgotten?