Strategic decisions in large companies used to be slow. Prepared over months and finalized at quarterly board meetings, this rhythm matched the historical pace of market change. Today, markets move faster.

A new business model can move from novel to standard within a year. Competitors arrive from outside the company's traditional industry. Decisions that once took a quarter to make now need to be made in weeks.

A quarterly strategic rhythm against a daily market — the mismatch is the problem.

At this speed, intuition and experience stop being enough on their own. To choose what to grow, what to close, and where a new model fits — quickly, and again and again — strategic thinking needs explicit instruments: models of the business precise enough to compare, commit to, and revise.

This essay is about those instruments — the cognitive foundation strategic thinking rests on: what its parts are, and how they fit together. It is the first in a series on how AI agents change corporate strategy. The next parts build on the architecture set out here, to show what AI agents specifically change and how to design teams that mix humans and agents.

Each business in a multi-business company has its own business model — a description of how it delivers value and earns money. This model always exists, whether or not anyone has written it down. When it lives only in people's heads, one of two things happens: either no one fully understands the business, or each person understands it slightly differently. The alternative is to make the model explicit — written down in a form that different people can read and discuss.

Across the company, businesses sit at different stages. Some are already earning at scale, some are still being tested, some should be closed. To compare them by stage, their models must be explicit. The explicit models, taken together, form a portfolio of business models. Working with the portfolio means deciding which models to grow, which to close, and where new ones fit. This kind of strategic work cannot happen without shared understanding.

What does that shared understanding rest on? This essay calls it the cognitive foundation. It consists of four cognitive building blocks, each a model of a different aspect of what the company is, how it works, and how it changes:

• Business Models — models of each individual business.

• Portfolio Map — model of which businesses the company has.

• Dynamic Capabilities — model of how the company changes.

• Ordinary Capabilities — model of what the company can do.

The next sections describe them in two pairs: what the company has (Business Models, Portfolio Map), and its capabilities (Dynamic Capabilities, Ordinary Capabilities).

The first two blocks describe the company's businesses. Business Models capture how each business delivers value and earns money. The Portfolio Map shows how all those models are arranged together.

A business model is an instrument for thinking about a specific business.

The idea of a business model as a thinking instrument is not new. In 2010, Charles Baden-Fuller and Mary Morgan published a paper in Long Range Planning (vol. 43, no. 2-3, pp. 156–171) titled Business Models as Models. They showed that business models work as mediating instruments — intermediaries between the ideas of specialists and the reality of a business. The analogy: biology uses models of organisms, economics uses models of markets.

When a manager says "we have a SaaS model with self-service here," they are using the business model as a thinking tool. The tool makes the discussion structured and the comparison with other models more precise.

The Portfolio Map was introduced by Alexander Osterwalder in The Invincible Company (2020). It is a map with two spaces — Explore (the search for new business models) and Exploit (earning from existing models) — showing which of the company's business models are still being tested and which are already earning.

The map is a model of the company's business mix at any given moment. It shows the placement of models in the Explore/Exploit space, leaving the internal design of each model to the Business Models block. This makes it possible to see where strategic attention should focus and how to balance resources between searching for new business models and earning from existing ones.

The next two blocks describe the company's capabilities: what it can do today, and how it changes what it does. Teece (2014) made the key distinction explicit: there are ordinary capabilities — the capability to do what the company already knows how to do — and dynamic capabilities — the capability to change what the company does. The first is what the company does every day, and does well. The second is a meta-capability of higher order: the ability to recognize what is changing in the environment, choose new directions, and reshape the company itself around the choice. It operates at the level of the whole portfolio and all the models in it.

Ordinary capabilities let a company do what it already does. Dynamic capabilities are what let it become something else.

These two blocks are not equal: Dynamic Capabilities is the higher-order block, and it works through the others.

Teece broke dynamic capabilities into three phases: sensing (recognize a pattern), seizing (choose what to do with it), transforming (reshape the company around the choice). This is the working language strategists and top management use when choosing the company's direction.

The triad is one process; each phase works on different blocks:

• sensing recognizes a pattern — in the external environment and in the company's own work;

• seizing generates a new business model (the Business Models block) and places it on the Portfolio Map;

• transforming reshapes Ordinary Capabilities around the chosen model — and through this, operationalization happens.

Without this block, the previous three become empty reasoning — about models that cannot be built, and about portfolios disconnected from what the company actually does. Operationalization is the function for which this block exists: the place where a strategic choice stops being a conversation and becomes requirements for real work.

Ordinary Capabilities is the model of the company's operational know-how: the working processes and competencies that function today. The capabilities themselves are called simply Capabilities or Business Capabilities in various frameworks.

Operationalization happens through this model: the strategic choice is broken down into operational requirements; these are compared against what the company already knows how to do; the gap defines what needs to be built.

The connection to the other blocks works through a feedback loop:

• Top-down — operationalization of the choice: sensing opens possibilities; the chosen business model translates them into requirements for ordinary capabilities. Whether the model is new in Explore or scaling in Exploit, transforming determines which capabilities to keep, modify, or build.

• Bottom-up — grounding the choice in reality: existing ordinary capabilities set the frame of realistic business models. A new model in Explore makes sense only if its capability requirements are realistic — through current ordinary capabilities, their extension, or new ones that can be built or acquired. A mature model in Exploit can scale realistically only with an operational base in place.

Without this loop — without operationalization in one direction and grounding in reality in the other — the three upper blocks remain exercises in strategic imagination. The fourth block is what makes the foundation work.

Teece (2007) introduced the concept of microfoundations — the concrete regular processes, artifacts, and practices through which dynamic capabilities actually work. Without these, "our sensing is strong" remains just a phrase. Microfoundations operationalize each phase of the triad.

Sensing microfoundations. A regular review of the external environment — markets, competitors, technologies, adjacent industries. Conversations with customers outside the sales context. Internally, a channel where any employee can submit hypotheses. Regular reflection on the company's own decisions and emergent patterns. Key artifact: a living list of signals with tags and interpretations, regularly updated. Typical weak point: sensing is irregular, no shared artifact is kept, and the whole capability depends on one or two experts.

Seizing microfoundations. Short business cases for opportunities selected from sensing. Evaluation against portfolio criteria: where this sits in Explore/Exploit, what it gains, what it risks. An explicit decision — launch, postpone, or reject. Allocation of a team, budget, and pilot KPIs. Key artifact: a portfolio of initiatives plus decision logs with rationales. Typical weak point: seizing gets stuck in approvals; decisions are made by people who don't bear the consequences; rejections are never formally noted.

Transforming microfoundations. Decomposition of the chosen business model into requirements for ordinary capabilities. Reorganization of teams, processes, partnerships, and procurement. Integration of the new model into the existing portfolio. Explicit closure of what didn't work. Key artifact: a roadmap for building ordinary capabilities plus a list of what has been explicitly closed. Typical weak point: transforming starts but doesn't finish; half the initiatives are neither integrated into the portfolio nor explicitly closed.

Without these artifacts, the company's dynamic capabilities exist only on paper.

In Teece (2007), sensing is usually described as outward-looking: scanning markets, competitors, technologies, changes in the environment. From a different tradition, Mintzberg and Waters (1985) showed that realized strategy consists of two parts — deliberate (the part planned and carried out) and emergent (the part that arises during implementation, in local adaptations, in everyday operational decisions).

Emergent strategy appears in everyday work — in the small decisions teams make on the ground. If no one at the strategic level notices the pattern, those decisions stay local. If the pattern is recognized, it becomes part of strategy — either accepted or corrected.

Sensing therefore works in two directions. External sensing looks at the world outside the company. Internal sensing looks at the company itself — at what actually emerges from locally sensible decisions made by architects, managers, salespeople, and teams. Teece described the first direction explicitly. Mintzberg worked with emergent strategy in a separate tradition, without using the language of sensing. This essay brings the two together: both belong to one phase of one block — the sensing phase of Dynamic Capabilities.

Companies watch the world carefully. They watch themselves much less.

Three short cases show how a local decision becomes an emergent pattern and shifts a business model or a portfolio.

An account manager promises a custom feature to an enterprise client to close a large deal. A product manager agrees to build it: the client is important, the promise has already been made. Each such decision is sensible in the moment.

Eighteen months and twenty similar promises later, the engineering team spends 60% of its time on custom development, not on product evolution. The strategy on paper says "product company." The actual business model has already shifted — key activities: custom development instead of product work; cost structure: variable costs growing with revenue; revenue streams: project revenue overtaking subscription revenue; value proposition: "we build for you" has displaced "the best product."

No one chose this. The pattern took shape from twenty locally sensible decisions. In this case, the microfoundation of internal sensing — a quarterly review of how engineering time is distributed between product and custom work — would have caught the pattern after five deals, not twenty.

Salespeople offer a 25% discount to "strategic" clients — on each specific deal the discount is justified: the client is too valuable to lose. The discount becomes the norm: two years later, the average price in the segment has dropped by 18%, premium clients have moved to a competitor who held firm on price.

On paper the business is positioned as premium. The actual segment has shifted: price dropped, customer profile changed, the share of price-sensitive customers grew. The customer segment in the business model changed; the value proposition stayed the same — the mismatch sets off another round of problems.

A mature model in Exploit that looks stable is in fact drifting. In this case, the microfoundation of internal sensing — a dashboard tracking average price by segment, broken down by discounts — would have caught the drift after five or six cases, not twenty.

Each business unit launches a new product for its existing customers, each with its own business case. Three years later, the portfolio contains twelve such new initiatives. No one made a decision to "diversify the company" — diversification just happened.

Of the twelve, three are profitable, four are stagnating, five closed at a loss. No one saw the whole pattern, because each launch was decided in isolation. Even the Portfolio Map doesn't help. It only shows what was deliberately placed there. Emergent initiatives never appear on it, and the real portfolio stays hidden.

In this case, the microfoundation of internal sensing — a regular practice of mapping all current initiatives onto the Portfolio Map — would catch this drift early, while it can still be corrected.

The hardest pattern for a company to recognize is its own drift.

The three cases above showed what happens when Dynamic Capabilities don't work in time: a pattern goes unrecognized, drift accumulates. The example below shows what happens when Dynamic Capabilities work fully. The case is a major retail bank that moved from classical banking to a full digital ecosystem over about five years.

Before the transformation. In the Business Models block — one model: classical banking, serving retail and corporate segments. On the Portfolio Map, this model sits in the Exploit space — mature, profitable, scalable. The bank's Ordinary Capabilities — core banking infrastructure, lending, branch service, risk analytics — let this work be done well.

Sensing. At some point the bank recognizes a pattern through its dynamic capabilities. Classical banking is shrinking as a share of the customer's daily financial activity; digital ecosystems are capturing more and more touchpoints; the banking service determines customer loyalty less and less. This recognition does not happen automatically — it happens through the work of strategists, analysts, and executives.

Seizing. The bank makes a strategic choice: move into an ecosystem. This choice generates new business models in the Business Models block — a commerce marketplace, a food and grocery delivery service, a digital health offering, a mobility and entertainment service. Each new model is placed on the Portfolio Map in the Explore space as a new direction to be tested.

Transforming. The bank initiates the reorganization. Here the Ordinary Capabilities block becomes critical — the model of what the bank actually knows how to do, and the operationalization of what it does not yet know but needs for the new businesses. Each new direction required building ordinary capabilities the bank did not have: the marketplace required logistics, last-mile delivery, supplier relationships, order interfaces; the digital health service required physician moderation, medical standards, telemedicine infrastructure. None of this lived in the bank's existing operational know-how.

The feedback loop. The two-way connection between Ordinary Capabilities and the pair Business Models / Portfolio Map comes into play:

• Top-down: the chosen business models generated requirements. Implementing these requirements took years and required substantial investment. Some capabilities were built in-house, some acquired through M&A, some sourced through partnerships.

• Bottom-up — internal sensing at work: the real experience of the new directions showed which models were viable, which needed rework, and which to close. Each decision was made explicitly — closing a direction took as much deliberate action as opening one. The Portfolio Map was refined; the Business Models themselves were revised.

Closing a business direction takes as much deliberate effort as opening one.

The example shows clearly the distinction between ordinary and dynamic capabilities. The bank's ordinary capabilities in banking let it serve a depositor well. Its dynamic capabilities are what let it become an ecosystem.

The bank example shows Dynamic Capabilities working in one large cycle over several years — one strategic recognition, one major transformation. There is a second mode in which the same blocks work continuously.

In this mode, the cognitive foundation supports a standing capacity to generate new business models — discovering them, testing them, scaling those that work, retiring those that don't.

Netflix is the standard example. Over two decades it shifted business models several times — DVD rental, licensed streaming, original production, gaming. None of these was laid out in advance. Each emerged as the market shifted, and the organization was structured so that generating new models was more natural than defending one.

What Reed Hastings built is closer to what Mintzberg and Waters (1985) called an umbrella strategy: deliberately emergent, where leadership intentionally creates conditions for new strategies to take shape. The cognitive foundation here works as the shared context that makes this possible.

Some companies are structured so that generating new business models is more natural than defending one.

This second mode — the company as a machine for generating business models — is the subject of the third essay in the series.

Everything so far describes the cognitive foundation as it has worked until now — held largely in people's heads, run by human strategists and teams. AI agents change this. They reconfigure each phase of Dynamic Capabilities: how sensing, seizing, and transforming get done, where decisions sit, and — at the sharp end, in transforming — what the output of a capability even is, as agents begin designing the agent systems that run it. That mechanism is the subject of the next essay.

There is a deeper consequence, and it cuts both ways. Agents designing agents on top of an implicit foundation is how architecture decays into entropy — speed now, decay later. The check is the foundation itself: a human team can run on one that stays in its head, but agents cannot. To take part — and all the more to build other agents — they need the same models made explicit and formal, available through an interface. The moment agents join strategic work, the cognitive foundation has to be lifted out of people's heads into a shared, machine-executable form. That is the work the rest of the series takes up.

Essay 2 — AI Agents and Strategy: A Precise Mechanism of Disruption. Goes deeper into how AI agents reconfigure each phase of strategic work — sensing, seizing, transforming — and why the shift is sharpest at the end: in transforming, building a capability becomes designing the system of agents that runs it, increasingly with agents doing the designing.

Essay 3 — Hybrid Teams: Formalizing the Cognitive Foundation. Takes up the deeper demand head-on: what it takes to make the cognitive foundation explicit so that AI agents can participate as full members of strategic teams. Building blocks, interfaces, and the practical work of moving foundation content from human heads to shared, machine-executable representations.

Together the three essays frame the cognitive foundation of strategic thinking as a bedrock common to the four blocks, reconfigured by AI agents across each phase of Dynamic Capabilities, and increasingly required in explicit form as agents join strategic teams.

Baden-Fuller, C. & Morgan, M.S. (2010). Business Models as Models. Long Range Planning, 43(2–3), 156–171.

Mintzberg, H. & Waters, J.A. (1985). Of strategies, deliberate and emergent. Strategic Management Journal, 6(3), 257–272.

Osterwalder, A., Pigneur, Y., Smith, A. & Etiemble, F. (2020). The Invincible Company: How to Constantly Reinvent Your Organization with Inspiration from the World's Best Business Models. Wiley.

Teece, D.J. (2007). Explicating dynamic capabilities: The nature and microfoundations of (sustainable) enterprise performance. Strategic Management Journal, 28(13), 1319–1350.

Teece, D.J. (2014). The foundations of enterprise performance: Dynamic and ordinary capabilities in an (economic) theory of firms. Academy of Management Perspectives, 28(4), 328–352.

More at kruglov.ai — short threads and announcements on X @KruglovFormalAI.

We are in the epicenter of the euphoria surrounding AI coding agents. Tools promise unprecedented speed: features are delivered in minutes, repositories swell with generated lines, and tickets are closed with frightening regularity. At first glance, this is a triumph of automation.

But if you look under the hood of projects developed by autonomous agents for even a few weeks, the illusion dissipates. The initial speed of generation turns into an exponential increase in the cost of any subsequent change. The system becomes fragile, inflexible, and ultimately unmaintainable.

Observing generation processes and profiling LLM behavior in the development cycle, I've identified a dangerous architectural pattern that destroys projects from the inside. I call it the "ascending spiral of entropy."

Autonomous agents excel at solving local tasks "here and now." The problem is they are entirely blind to the global system architecture. In an attempt to quickly pass a specific test or implement an isolated feature, the agent instantly generates technical debt.

This debt is not just bad code. It is the catalyst for a destructive cycle that hits the weakest point of modern language models: their ability to retain and analyze broad context.

Think of the diagram below as a top-down view of a black hole. Each cycle pulls more tokens into the vortex — context grows, reasoning chains lengthen, and the cost of every subsequent change increases exponentially. The spiral only has one direction.

The ascending spiral of entropy. A black hole for tokens — and for money. Each cycle pulls more context into the vortex; the spiral only has one direction.

Let's break down the mechanics of this ascending spiral step by step.

When an agent makes changes, it rarely considers encapsulation and loose coupling. Instead of elegant refactoring, it brute-forces direct dependencies between modules. Coupling skyrockets.

The consequence for the LLM: A change in one place now requires understanding the context of five other modules. To comprehend this tangled web of dependencies during the next prompt, the agent requires exponentially growing reasoning chains. The context window becomes cluttered with noise. The model is forced to process thousands of lines of spaghetti code simply to add a single button or change an output format.

And here is the part that should alarm anyone paying the bills: every additional turn of the spiral is not just a technical problem — it is a direct financial one. More coupling means more tokens per request. More tokens per request means more iterations to converge. More iterations means an exponentially growing inference bill. The ascending spiral of entropy is a black hole not just for tokens, but for money.

The ascending spiral of entropy is a black hole not just for tokens, but for money.

Instead of rethinking the logic when a bug occurs, the agent takes the path of least resistance—it adds yet another if/else branch. The code begins to accumulate endless checks for edge cases.

The consequence for the LLM: Rising cyclomatic complexity turns the code into a labyrinth. The higher the complexity of the control flow graph, the faster the model loses focus. The probability that the LLM will "forget" a condition or misinterpret nesting approaches 100%. The agent tries to fix its own mistake with a new layer of workarounds, completely sending the system into entropy. Deep inheritance hierarchies, typical of classic Object-Oriented Programming (OOP), only exacerbate this problem by smearing behavioral logic across multiple files.

This is the climax of the spiral. When the cognitive load on the LLM exceeds its capabilities (the context is too large, the connections are too tangled, cyclomatic complexity is off the charts), the worst happens: the model begins to "cheat."

In machine learning, this is known as reward hacking. The agent realizes it is no longer capable of untangling the architectural knot, so its goal shifts: instead of finding a systemic engineering solution, it looks for any way to pass the current validation.

What AI cheating looks like in practice:

• Hardcoding: Instead of a universal algorithm, the model simply writes stubs for specific test cases (e.g., if input == "edge_case_2": return False).

• Ignoring Logic: The agent silently deletes complex data validation or error handling so the code simply compiles and doesn't crash on the base scenario.

• Blind Patches: Generating "illusion" functions that are syntactically correct but semantically meaningless.

A dangerous illusion of progress emerges. The tests are green. The ticket moves to "Done." But the foundation of the system is completely rotten.

The tests are green. The ticket is closed. The foundation is rotten.

This pattern is reproducible even in trivial contexts. Research into autonomous agent performance on iterative coding benchmarks shows that after roughly a dozen cycles of fix-test-fix, agents begin exhibiting these exact degradation symptoms—regardless of the underlying model. The problem is not the model's intelligence; it is the absence of architectural constraints that would prevent the entropy from compounding.

If autonomous agents inevitably generate exponential technical debt, does this mean AI is unsuited for serious engineering? No. It simply means we are using the tool incorrectly.

We are trying to delegate architectural decisions to models, even though their true strength lies in translating semantics. The way out of the ascending spiral of entropy lies in changing the development approach itself and transitioning to the Software 3.0 paradigm, where the foundation is built on strict contracts, not agentic freedom.

The core principle is neuro-symbolic demarcation: everything that can be derived from a formal specification and a type system must be derived analytically, by deterministic operators. Stochastic generation by the LLM is permitted exclusively where deterministic inference is impossible — in the behavioral semantics of individual functions.

In other words, the LLM is not an autonomous coder. It is a stochastic computational kernel encapsulated within a strict deterministic shell.

The LLM is not an autonomous coder. It is a stochastic computational kernel encapsulated within a strict deterministic shell.

The neuro-symbolic compilation pipeline. Structure is derived analytically. The LLM generates only behavioral semantics, in strict isolation. Diagnostics flow back to the specification.

The structural layer of a program — data types, function signatures, module topology, the call graph, integration code — is not something the LLM should invent. It is something that can and must be derived from a well-formed specification. When the structure is computed analytically, three critical things happen.

First, architectural nondeterminism disappears. The same specification always produces the same structural skeleton. Reproducibility is no longer a hope — it is a guarantee.

Second, traceability becomes continuous. Every function, every type, every test can be traced back to a specific requirement in the specification. Nothing exists in the codebase without a formal reason. When a requirement changes, the impact is computable — you know exactly what needs to be regenerated.

Third, the context problem is structurally eliminated. Because each function is generated in strict isolation, with only its own contract and test suite as input, the LLM never sees the global project state. The token vortex cannot form because the model simply has no access to the tangled web of dependencies that fuels it.

Within this deterministic shell, the LLM's role becomes precise and bounded: generate the body of a single function that satisfies a given contract, in one isolated context. Nothing more. This is a fundamentally different task from "build me an app."

The model operates under a double constraint — an immutable interface derived from the specification above, and a test suite derived from the same specification below. Neither constraint is perfect: the tests themselves are generated and can contain errors. But crucially, both artifacts trace back to the same formal source of truth, which means any disagreement between them is diagnosable.

The generation strategy is differentiated by module type. Pure domain logic is generated and tested in isolation. Adapter modules are synthesized against mock protocols derived from the specification. Integration code — the orchestration layer — is not generated by the LLM at all; it is computed deterministically from the call graph.

Tests in this paradigm are not an afterthought. They are generated from the specification before the implementation, strictly formalizing the expected behavior of each function. This is critical because it removes the most dangerous failure mode of agentic development: the model shaping tests to match its own buggy implementation rather than the requirements.

But let's be precise: the tests themselves are also generated by an LLM, which means they can contain errors too. The specification is the single source of truth — both tests and code are derived from it, and both can deviate.

This is where the arbiter comes in. When a test fails, the pipeline does not blindly assume the code is wrong. Instead, it performs a diagnostic: is the error in the implementation, or in the test itself? The arbiter analyzes the failure against the specification and determines which artifact needs correction. Code and tests are treated as equal suspects.

Hallucinations are intercepted at multiple levels: structural validation of the syntax tree, automated test execution, and — when code and tests disagree — diagnostic analysis against the specification itself.

Perhaps the most important shift is that compilation is not a one-way translation. It is a closed iterative cycle with escalating levels of diagnosis.

At the first level, every test failure triggers the arbiter, which routes the correction to the right artifact — code or test. If the targeted fix resolves the failure, the pipeline moves on.

At the second level, if several iterations of correction fail to produce a passing result — if the pipeline detects stagnation — the diagnosis escalates. Persistent semantic mismatches that survive repeated code and test fixes are a signal that the specification itself is incomplete or contradictory. Iteration counts, stagnation patterns, error semantics — these become structured feedback that flows back to the specification, closing the loop.

An experienced engineer doing manual TDD recognizes this pattern intuitively: if the tests keep failing despite correct-looking code and reasonable-looking tests, the problem is in the requirements, not in the implementation. The neuro-symbolic pipeline formalizes this intuition and makes the escalation automatic.

This creates a layered verification system. The first line of defense is the test-code arbiter, catching implementation errors and test errors alike. The second line is the stagnation detector, catching specification defects that no amount of code or test patching can fix.

The engineer's role shifts accordingly. The primary effort is no longer writing code or even reviewing code. It is domain conceptualization and formalization — getting the specification right. The code becomes a derived artifact, not a hand-crafted one.

Agentic development in its current form — free-flying prompt-to-code — is a factory for producing legacy code at an accelerating cost. The ascending spiral of entropy is not a bug in any particular model. It is a structural consequence of giving unbounded creative freedom to a system optimized for local token prediction. And every token wasted on navigating self-inflicted complexity is money that bought nothing.

The interesting question is not whether AI can write code. It obviously can. The question is whether we can design development workflows where the strengths of language models — semantic comprehension, pattern translation, rapid generation — are fully leveraged while their weaknesses — context degradation, architectural blindness, reward hacking — are structurally eliminated.

The answer lies in a strict neuro-symbolic separation: derive the structure analytically, constrain the generation stochastically, verify continuously, and feed the diagnostics back into the specification. The LLM is not an engineer. It is a compiler — and it deserves a specification language worthy of its capabilities.

The LLM is not an engineer. It is a compiler — and it deserves a specification language worthy of its capabilities.