The journey almost always runs the same shape. There is a brief lift at the start, when the idea is still theoretical and everyone who hears it agrees. That lift is not traction, it is agreement, and agreement is free. Then the unit meets its first real customer and drops hard, because reality asks questions the pitch never had to answer. What follows is the long flat stretch that nobody photographs. The founder is carrying the unit alone here, sometimes for years, testing and discarding and rebuilding while nothing on the outside appears to change. This is where most units are set down, and they are almost never set down because the idea was wrong. They are set down because the carry got heavier than the belief. Then, quietly, something holds. A customer renews without being asked. A number stops falling. That is the point where the load starts to transfer. Backers join, a team forms, and for the first time the unit is being held up by more than one pair of hands. Eventually it stands on its own and stops being carried at all.

So here is what I actually think entrepreneurship is. It is not the idea, and it is not the company that sometimes forms around it. It is the courage exercised, over and over, to move the entrepreneurial unit one more step through the valley. The valley is the long flat stretch on the curve, after reality sets in and before anything starts working. It is made of experiments that go nowhere, pivots that feel like admissions of failure, and the specific loneliness of rebuilding something for the third time while the people around you have quietly stopped asking how it is going. Nothing about it looks like progress from the outside. Then something starts to work, and the first real fit arrives, and then it arrives again in a sharper form, and eventually the thing scales. But every one of those points sits on the far side of the valley, and the only way anyone ever reached them was by continuing to carry the unit on a day when there was no evidence that they should. That is why the journey matters more than the destination, and why the journey is the thing to optimise for. You do not get to choose whether the valley shows up. You only get to choose what kind of person is carrying the unit when it does.

I believe AI-native software needs its own constraint. Here is the one I came up with.

Your codebase has a maximum size. This is not a matter of taste. The limit is real, measurable, and smaller than you think.

The limit: half the context window of the AI model your agents use to build and maintain your product. This means the size of your core business logic and system context should not exceed half of the context window of whichever LLM you rely on.

Why half? The context window serves two purposes. The first half holds your code. The second half is where the agent reasons, plans, and generates. Fill the whole window with code and you leave zero room for thinking. Half for comprehension. Half for cognition.

The hardest part of software businesses was never building features.

Every experienced tech founder knows this. The hard part was identifying the smallest piece of useful software for a large enough customer segment, and then rallying people around the difficult work of customer acquisition, customer service, and retention.

Building software used to be expensive. Engineers cost a lot. This created friction, giving birth to iterative development processes, but it also imposed discipline. You had to choose: What do customers need most? What is the smallest thing worth building? The human cost of engineering kept teams focused. Constraints created clarity. The best companies in Silicon Valley grew this way.

Now AI agents build almost anything you ask for. The bottleneck has disappeared. The discipline disappeared with the bottleneck.

Free production leads to overproduction. Overproduction is the default failure mode of AI-native companies.

Non-technical founders and investors need to understand this. More features, more code, and more product surface area to maintain are no longer signs of progress. They signal a company without high-quality constraints, and sometimes, a fundamental lack of clarity.

Overproduction without scalable distribution and consumption creates massive leakage in value capture. You ship ten features. Two drive retention. The other eight add complexity that slows down the two that matter. Every line of code becomes a liability disguised as an asset.

Experienced builders know the tipping point. Code shifts from serving customers to serving itself. Complexity becomes the product's enemy. Teams spend more time managing software than improving the customer experience. The system starts to feel clunky, users begin to drop off, and your customer-facing teams silently grow frustrated.

In the old world, you reached that tipping point over years. In the AI-native world, you reach the tipping point in weeks. Agents never feel tired, never push back, and never say, "this is too complex, we should stop."

How do you know when to stop? When AI writes unlimited code for free, what is the signal that tells you enough?

It is the Half-Window Rule.

Your core business logic must fit within half the context window of the model that maintains your codebase. Measure your codebase in tokens. Compare it to half the context window. If you are over, your AI workforce is already degrading—not visibly, not dramatically, but silently and steadily.

The danger: nothing obviously breaks when you cross this line. The agent does not refuse. The code looks correct. Tests pass. The bug you reported gets fixed.

But the agent now operates without full comprehension of your system. The agent pattern-matches on fragments instead of reasoning about the whole. Subtle regressions appear. Logic gets duplicated in parts of the codebase the agent cannot see. Problems get "solved" by adding code where existing code should have changed.

You will not notice immediately. Velocity still feels high. Pull requests still flow. Each one makes the next slightly worse. Compound degradation works against you.

By the time you ask "why do our agents keep going in circles?" you are deep in the problem.

This rule is business discipline in technical clothing.

Simplicity becomes your competitive advantage when production costs nothing. Build the smallest codebase that delivers real value to customers. Every unnecessary feature, every unneeded abstraction, and every line of speculative code eats your AI workforce's cognitive budget. Eventually, these eat your company's ability to move.

The best products have always been the simplest ones that solve a real problem completely. The penalty for violating this principle now arrives faster and compounds harder. Your AI agents will not push back the way a frustrated senior engineer would have.

The rule scales with architecture. Single-product startup: applies to the whole codebase. Multi-service company: applies to each service independently. Any piece of your system that must be understood as a whole must fit within the boundary where your agents reason about the full picture.

Your product architecture will mirror the cognitive boundaries of your agents—whether you plan for this or not. The founders who design for this deliberately will outrun those who learn through pain.

This is not about perfection. You will not always stay under the line. Codebases grow. Features get added. Complexity accumulates. The point is aspiration, not rigid compliance. If you keep this rule in mind and stay close to the boundary, you will make better decisions about what to build, what to split apart, and what to delete. The constraint gives you a reference point when everything else says 'build more'. Sometimes this means re-designing your sub-agent architecture to suit the rule—very similar to how human teams divide ownership as they grow.

I aspire to follow this rule in my own work. Not because breaking the rule means instant failure, but because staying close to this constraint helps me build software that remains useful, maintainable, and valuable over time. The founders who orient around this will go far. The ones who ignore constraints entirely will learn through pain.

Good constraints do not guarantee success. They make success more likely by removing the most common ways to fail. The 12-factor app was a set of principles that didn't build your SaaS company for you, but if you followed them, your infrastructure worked when you needed to scale. The Half-Window Rule works the exact same way. Follow the spirit. Stay close to the boundary. Build useful software businesses that last.

Simplicity always wins. Now simplicity wins faster.

--------------------------------------------------------
About the Author: Abhishek Parolkar is the CEO of https://brain.pe - which helps Private Equity firms create their digital AI brains for their own firm or specific deals. You may have adopted AI, but has the AI adopted you?
Follow his work on Linkedin or X.

Bigger models. Bigger context windows. More tokens.

It feels right, the way carrying a bigger backpack feels right before a long trip.

But intelligence isn’t measured by how much you carry.

It’s measured by how much you can throw away and still know where you’re going.
That’s the part we’re missing.

The Trap of Perfect Memory

There’s a rare condition called hyperthymesia.

People with it can recall nearly every day of their lives. Nothing fades. It sounds like a superpower. It isn’t.

They struggle to move on because nothing becomes background. Every regret stays sharp. Every detour stays loud. The present never gets a clear stage.

Perfect recall makes living harder, not easier.

We’re doing a version of this to our machines. We celebrate longer context windows as if wisdom were just a larger buffer. It only benefits the platform providers: bigger context windows means more tokens to charge for (more utilisation).

But a longer scroll isn’t more insight. It’s just more scroll (for humans and for machines).

What Intelligence Actually Does

When you solve a hard problem, you don’t replay your entire past. You reach for a pattern. A principle. A sharp example. Everything else you forget on purpose.

That’s not a flaw; it’s the mechanism.

Intelligence compresses. It keeps the essence and discards the rest.

Call it systematic compression of context

• Summarize the idea to its transferable core.

• Drop the specifics that don’t change the decision.

• Keep the map, not every footstep.

Humans do this instinctively. The best thinkers compress best. Machines will need to learn it deliberately.

The frontier isn’t bigger context. It’s better compression.

From Artificial to Institutional

Now widen the lens.

Individuals drown in their GPT/Claude chat sessions, slack and endless meeting transcript emails. GenAI amazingly creates lots of stuff quickly because it can. Teams forget why a decision was made. Companies lose the reasoning that still shapes their way forward.
Most organizations mistake volume for progress. They dump old PDFs, HR policies, and board decks into an AI layer and call it transformation. In reality, they’ve just given enterprise search a new UI. “Search” is one small part of information discovery — not a device of intelligence.

This is not a storage or indexing problem. It’s a compression problem.

Artificial intelligence turns into institutional intelligence only when an organization can compress its experience into usable, durable context — and then make that context easy to retrieve at the moment of choice.

Without compression, knowledge is a junk drawer.

With compression, it’s a playbook.

The System (Simple, but Not Easy)

Systematic compression of context is a habit with three moves:

1. Collect broadly (machines).

Pull the raw material from docs, chats, tickets, repos. Don’t judge yet.

2. Compress aggressively (humans).

Summarize the decision, the why, and the transferable pattern. One paragraph beats ten. Name the principle. Tag the context. Delete the rest.

3. Maintain lightly (rhythm).

When reality changes, update or archive. Stale context misleads more than no context.

Most teams stop at step one and call it “knowledge”

The compounding starts at step two.

Curation isn’t overhead. It’s the multiplier.

How It Feels When It Works

At the personal level: your notes stop being transcripts and start being tools.

You keep the argument, not the meeting.

At the team level: decisions come with a short “Decision + Why + When It Breaks” block.

Future you can reuse the reasoning without replaying the thread.

At the organization level: every shipped feature, incident, experiment, and sales win gets compressed into patterns the whole company can use.

Support answers get cleaner. Product bets get bolder. New hires ramp using prior judgment, not tribal lore.

This is how knowledge starts to compound.

Not by remembering everything, but by remembering the right shape of things.

The Missing Role

Someone has to own the quality of compression.

Call them the Context Manager.

They aren’t a librarian counting documents.

They’re an editor of intelligence.

• They enforce the “one-paragraph why.”

• They kill fluff and stale pages.

• They wire the system so AI pulls from compressed, trusted context — not raw noise.

In a world chasing more tokens, their job is to teach the machine what to forget.

The Compounding Curve

Here’s what changes when you get this right:

• Speed: Fewer rediscoveries of old answers.

• Quality: Decisions carry forward the best prior judgment.

• Onboarding: New people inherit patterns, not puzzles.

• AI performance: Retrieval isn’t random; it’s from vetted, compressed context.

You start to feel it in weeks, not quarters.

The org thinks with a memory that doesn’t bog it down.

The Real Advantage

Everyone can buy the same models.

Almost no one will build the same context.

The advantage won’t be the size of your context window.

It will be the sharpness of what’s inside it.

Systematic compression of context is how artificial intelligence becomes institutional intelligence.

It’s how a company learns faster than it forgets.

We don’t need bigger models.

We need smarter forgetting.

I recently heard a seasoned programmer complain that AI was turning him into an "AI Agent Manager" rather than code/software craftsman. "I actually enjoy programming!" he said, frustrated that a programmer's new role involves orchestrating AI agents instead of writing code themselves. As a programmer myself who knows both lawyers and poets, I realized they're facing the same dilemma with language in the age of AI.

Most people think lawyers and poets are opposites. Lawyers seem rigid, bound by precedent and procedure. Poets appear free, chasing inspiration wherever it leads. One group wears suits and bills by the hour. The other wears vintage jackets and teaches adjunct classes. Law is about winning arguments. Poetry is about expressing feelings.

Both of these stereotypes are wrong.

Lawyers and poets are much more alike than different. They're both makers, in Paul Graham's sense of the word. Along with programmers, painters, and writers, what lawyers and poets are trying to do is make good things with language. They're not following some predetermined formula, though if they discover new techniques while crafting their work, so much the better.

I discovered this connection when I started paying attention to how both groups actually work. Watch a lawyer drafting a motion, and you'll see something that looks remarkably like poetry. They're searching for the precise word, testing different rhythms, building toward a moment of revelation. The goal isn't just to convey information—it's to create an experience in the reader's mind.

Legal writing, when done well, is full of metaphor. We talk about "intellectual property" as if ideas were real estate. We describe corporations as "persons" and treat contracts as "living documents." These aren't just convenient fictions; they're the same kind of metaphorical thinking that drives poetry. Both lawyers and poets understand that language doesn't just describe reality—it shapes how we see it.

Consider Wallace Stevens, who spent his days as an insurance executive and his mornings composing poetry during his walk to work. To most people, this seemed like a contradiction. How could someone spend their days processing surety claims and their evenings writing lines like "The only emperor is the emperor of ice-cream"?

Stevens himself didn't see the contradiction. "Poetry and surety claims aren't as unlikely a combination as they may seem," he once wrote. "There is nothing perfunctory about them, for each case is different." He understood that both insurance law and poetry required the same fundamental skill: taking the complexity of human experience and finding the precise language to capture it.

Stevens wasn't unusual. Archibald MacLeish edited the Harvard Law Review before becoming a three-time Pulitzer Prize winner. Edgar Lee Masters was Clarence Darrow's law partner when he wrote Spoon River Anthology. Lawrence Joseph, a contemporary poet, puts it directly: "In the United States the language of law covers every social, economic and political issue... I've used it in my poetry."

What these lawyer-poets understood is what my programmer friend is rediscovering: the deep satisfaction of making something with your hands, whether those hands are holding a pen or typing code. There's a joy in finding exactly the right word, crafting the perfect sentence, building an argument that unfolds with inevitable logic. It's the same pleasure hackers get from elegant code or painters get from capturing light.

But there's a practical reason why so many poets have been lawyers. Law pays well enough to support poetry. Stevens could afford to walk to work composing verses because his insurance job provided financial stability. Poetry rarely pays the bills, but law often pays them quite generously. This isn't compromise—it's strategy. The day job enables the love work.

More importantly, the constraint of legal language can actually enhance poetic creativity. When you spend your days crafting precise, economical prose, you develop an ear for rhythm and an eye for the essential. Legal writing teaches you to cut every unnecessary word, to build arguments that flow inevitably from premise to conclusion. These are exactly the skills poetry demands.

Justice John Paul Stevens (no relation to Wallace) once said, "The study of English literature, especially lyric poetry, is the best preparation for the law." He was right, but the reverse is also true. Law is excellent preparation for poetry. Both require you to understand how language works on multiple levels simultaneously.

Now AI threatens to disrupt this symbiotic relationship. Language models can draft contracts, write briefs, and even compose poems. The same force that's pushing programmers away from hands-on coding is pushing lawyers toward becoming "legal project managers" and poets toward becoming "prompt engineers."

This is what I call the promotion paradox. The better AI gets at the core work, the more we risk being "promoted" away from the thing we actually love doing. Lawyers who entered the profession because they enjoyed crafting arguments find themselves managing AI outputs. Poets who love the feel of words in their mouth find themselves engineering prompts for text generators.

The parallel with programming is exact. My programmer friends didn't become a programmer to manage other programmers or oversee automated systems. Theybecame a programmer because they enjoy the puzzle of turning thoughts into code, the satisfaction of making software that actually works. When AI takes over the coding, they lose the thing they loved about the job.

But here's what I think both lawyers and poets can learn from hackers: the answer isn't to resist the tool, but to understand what the tool can't do.

AI is remarkably good at pattern matching and recombination. It can write a serviceable brief by following templates and precedents. It can generate poems that follow established forms and echo familiar themes. What it can't do—at least not yet—is understand what it means to be human in a specific moment with a particular problem.

When Stevens walked to work composing poetry, he wasn't just arranging words according to patterns he'd absorbed from other poems. He was processing his experience of being a middle-aged insurance executive in Hartford, Connecticut, watching the morning light hit familiar buildings, thinking about mortality and meaning and the strange beauty of ordinary life. The poetry emerged from that specific consciousness encountering that specific moment.

Similarly, when a skilled lawyer crafts an argument, they're not just following procedural templates. They're reading the judge's previous opinions, sensing the emotional undercurrents of the case, understanding how this particular client's story fits into larger questions of justice and human nature. The legal argument emerges from that specific understanding of this specific situation.

AI can simulate both processes, but simulation isn't the same as experience. The question becomes: do we want the simulation, or do we want the real thing?

I think the answer depends on what we're optimizing for. If we just want efficiency—the fastest contract, the most prolific poetry output—then AI is probably the answer. But if we want the satisfaction of craft, the pleasure of making something with our own minds and hands, then we need to be more careful about where we deploy these tools.

This is where the "vintage activity" concept becomes relevant. After recording technology was invented, playing guitar didn't disappear. It became something people did for different reasons—not primarily to distribute music to large audiences, but for the pleasure of making music in the moment. Live performance became more valuable, not less.

I suspect something similar will happen with legal writing and poetry. The routine work—standard contracts, formulaic briefs, greeting card verses—will increasingly be automated. But the craft work, the instances where language needs to capture something uniquely human, will become more valuable, not less.

The lawyer who can sense what's really at stake in a case and translate that into compelling prose won't be replaced by AI. The poet who can find fresh language for universal experiences won't be supplanted by text generators. But both will need to be conscious about which parts of their work they're willing to automate and which parts they insist on doing themselves.

This requires a different kind of choice than previous generations faced. Stevens didn't have to decide whether to let a machine write his insurance reports so he could focus on poetry. Today's lawyer-poets have to actively choose craft over efficiency, presence over productivity.

The programmers who are navigating this transition successfully seem to fall into two camps. Some embrace the role of AI orchestrator, focusing on high-level architecture and letting machines handle the detailed implementation. Others specialize in the kinds of problems that still require deep, hands-on engagement with code.

Lawyers and poets face the same choice. Some will become AI managers, focusing on strategy and oversight while machines handle the routine language work. Others will double down on the irreducibly human aspects of their craft—the moments where language needs to carry not just information but genuine understanding.

Neither choice is wrong, but it's important to be conscious about which one you're making. If you became a lawyer because you love the feel of language taking shape under your hands, don't let efficiency arguments push you into a role you'll hate. If you write poetry because you need to find words for experiences that don't yet have words, don't let productivity tools turn you into a prompt engineer.

The great revelation from Paul Graham's essay is that hackers and painters are both makers—they're trying to create things that work and matter. The same is true of lawyers and poets. They're both trying to make language do something it hasn't done before: capture a specific aspect of human experience with precision and force.

AI can help with this work, but it can't do this work. The difference matters. Understanding the difference—between assistance and replacement, between tool and craftsperson—might be the most important skill for anyone who works with language in the age of AI.

What gives me hope is that the people who are most passionate about their craft seem to intuitively understand this distinction. My programmer friends aren't worried that AI will replace programming. They're worried that AI will replace the kind of programming they love. The solution isn't to reject AI, but to be intentional about how we use it.

Stevens walked to work because he needed the rhythm of his steps on the pavement to match the rhythm of verses forming in his mind. He couldn't have composed those poems sitting at his desk, and he certainly couldn't have composed them by prompting a text generator. The walking was part of the work, not just preparation for the work.

The question for contemporary lawyers and poets is simple: what's your equivalent of Stevens' morning walk? What part of your job/practice is irreducibly human? requiring your specific consciousness engaging with specific problems? That's the part to protect. That's the part that makes you a maker, not just a manager.

The rest can probably be automated. And that might not be a loss—it might be a liberation. If AI can handle the routine contracts and formulaic briefs, maybe lawyers can spend more time on the cases that actually matter. If text generators can produce stock poems and greeting card verses, maybe poets can focus on the lines that actually sing.

The future belongs not to people who can compete with machines at their own game, but to people who understand what games only humans can play. For lawyers and poets, that game is language itself—not just the patterns and structures that AI can learn, but the lived experience that gives those patterns meaning.

In the end, lawyers and poets face the same choice my programmer friends face: efficiency or craft, productivity or presence, optimization or love. The answer isn't obvious, and it isn't the same for everyone. But it's a choice worth making consciously, because the alternative—drifting into roles we never wanted—is a kind of professional sleepwalking.

The lawyers and poets who stay awake, who choose their relationship with AI rather than letting it choose them, will be the ones who keep language alive as a human art. And in a world of increasingly sophisticated machines, that might be the most important work of all.

Let’s fix that.

The Fog Around AI

Buying GPUs or negotiating LLM cloud credits isn’t a strategy.
Hiring a chief-something-officer isn’t a strategy.
Running a pilot that never ships? Still not a strategy.

A real AI strategy answers one simple question:

How will we, the people who work here, get smarter, faster, and braver because AI is in the room?

To make that happen you only need three layers.
Think of them as concentric circles, moving inward from “me” to “we” to “all of us” (which is the core).

Traditionally, transformation strategies struggled to resonate with employees focused on day-to-day impact because they couldn't relate to the conversations of the board-rooms. For example, while a multinational burger chain's aim to become data-driven matters to the board, it means little to frontline staff making burgers or handling cash. AI, however, impacts everyone's workflow directly and offers tangible benefits to each role. This is the gift of AI for the change leaders that we must embrace.

Layer 1: Me & My AI

Start small. Start personal.

1. Notice the friction.
   Where do you waste minutes copying, pasting, hunting, guessing? That’s the opening for automation or suggestion.

2. Pick one task.
   Summarize the document. Draft a first email. Label yesterday’s data. Let the model try, then edit.

3. Measure the feeling.
   Did the work get lighter? If you finished sooner, spend the surplus on the work only you can do.

4. Make AI the Personal Strength.
   Have you hired your first personal AI agent(s) that is automatically drafting emails for you, preparing you for your day or helping you reflect on your 1-to-1s with the manager.

This layer isn’t about mastery. It’s about confidence.
When every individual feels, “AI makes me better,” adoption isn’t an initiative; it’s momentum.

Layer 2: Us & Our AI

Work is a team sport. Solo wins are nice; shared wins change culture.

1. Show your homework.
   Bring your AI-assisted draft to the discussion table. Let teammates see how you use AI. Create space for Human+AI Collaboration in a group setting.

2. Blend perspectives.
   Marketing asks the model for headlines. Legal asks it for risk flags. Put those prompts together. Magic happens in the overlap.

3. Breed Human+AI Facilitators.
   The fusion of machine intelligence and human-ness is building the new orchestra, identify and reward the facilitators in the team that are driving the Human+AI Collaboration.

4. Write a tiny rulebook.
   One page. What’s allowed, what’s off-limits, how the humans work in loop with AI. Agree fast, refine often.

Done right, AI becomes the quiet teammate who never sleeps and never takes credit.
Productivity climbs. So does trust.

Layer 3: Our Organization’s AI Brain

Now the heavy lift: turning scattered wins into a system.

1. Collect the crumbs.
   Every prompt, every project in loop with AI, every outcome teaches the larger brain. Capture that data on purpose, not by accident. Curate the collective wisdom and shape it into an organization's prefrontal cortex. The one that acts like the organization's system prompt curated from pristine organisational learnings instead of a RAG built on disjointed data dump of company's policy documents.

2. Govern with light hands.
   Guardrails matter, but bureaucracy kills learning. Automate the checks—bias tests, privacy filters—so humans stay focused on decisions.

3. Invest with intent.
   Tools age quickly; habits last. Spend less on shiny expensive LLM Models, more on shared AI deployment methods that works for everyone, LLM-ready data, and ongoing coaching for Human+AI Collaboration.

When the organization thinks in loops—people train models, models train people—you’ve built an AI advantage that compounds.

AI Strategy Adoption Compass

The true test of your AI strategy isn’t its length or its jargon. It's the clarity. Can you distill its essence into a single, powerful line that every employee – from the boardroom to the frontline – understands and feels? Push yourself ruthlessly towards this simplicity. If your strategy can’t survive the "one-line test," it’s likely still trapped in the fog. True north is found in a sentence like this: "We progress by enabling everyone to Participate with their AI, Facilitate team AI collaboration, and build our collective Organization Brain."

This is the power of focus. When your strategy becomes that clear – Participate (My AI) => Facilitate (Team's AI) => Progress (Organization Brain) – it stops being a document and starts being a compass. It guides daily decisions, fuels individual initiative, and aligns every layer of your organization towards a future where humans and AI together are fundamentally smarter, faster, and braver. Now, go sharpen your strategy until it cuts through the noise in a single, resonant line. What's your AI Strategy?

Executive Summary

Business software has stagnated for three decades, stuck in a paradigm where objects and CRUD operations define our work. Despite massive computing advances, we've merely moved these object-manipulation interfaces to the cloud rather than fundamentally rethinking how software models business processes.

This essay proposes Finite Object State Machines (FOSMs) as a transformative alternative. Unlike CRUD systems that allow arbitrary field edits, FOSMs model business entities as objects moving through explicit, well-defined state transitions. This approach naturally captures business rules, enforces process compliance, and creates audit trails.

More importantly, FOSMs provide the perfect structural foundation for human-AI collaboration. They create bounded contexts where responsibilities between humans and AI are clearly defined, preventing "AI gone rogue" scenarios while maximizing complementary strengths. AI makes FOSM implementation practical by automating the previously complex specification process, while FOSMs provide the guardrails that make AI deployment safe in regulated environments.

By combining FOSMs with modern AI capabilities, organizations can transcend the object-manipulation paradigm, creating business software that truly advances human work rather than merely digitizing it. This symbiosis offers a revolutionary framework for building adaptive, compliant systems where humans and AI collaborate seamlessly within clear, verifiable boundaries.

Introduction – "Work" & Computers

The role of computers has fundamentally been to support human activities and eventually blend so seamlessly into our processes that we redefine what constitutes "work" itself. In the Industrial age, paper forms became computer applications, eliminating physical document libraries and creating desk jobs connected via computer networks. Fast-forward to today, and "email" has itself become synonymous with "work." This transformation is not simply technological but represents a profound redefinition of human labor in the information age.

Section I – Business Software in Objects, Functions & Process Workflows

1. Objects & CRUD Dominance

For the last 30 years, software development has focused on translating business verbs and nouns into computational Objects and Functions. Since the late 1980s, the dominant abstraction for business software has been the database row. Enterprise suites such as SAP and Oracle codified the nouns of a business—Customer, Employee, Orders, Ledger—behind screens that offered just four principal verbs: Create, Read, Update, Delete (CRUD). These screens faithfully reproduced paper forms from the industrial age, eliminating kilometres of filing cabinets, yet also re-casting the very act of updating a record as "doing work".

2. Analytics & Insights Layer

As companies amassed mountains of rows, they needed to understand how and why those objects changed over time. This demand spawned data warehouses, BI tooling, and the modern analytics stack. The object model did not change; we merely added an observational layer that profiled its mutations.

3. Workflow Optimisation

Insights uncovered bottlenecks, giving rise to Business Process Management (BPM) tools that tried to stitch individual CRUD events into end-to-end workflows. At the same time, exploding data volumes turned into an infrastructure-scalability problem. For almost two decades the industry wasted time moving these objects—and their manipulation interfaces—to "someone else's computer": the cloud. Pioneers like Salesforce were right in the middle of this problem space, quickly capitalising on the need for ease of object manipulation over the internet (for most people: CRM in the cloud).

4. Integration Tangle

Cloud applications improved UX and availability and prepared us for remote work, but at the cost of a new mess: synchronising object state across dozens of SaaS silos. Integration-platform-as-a-service players such as Zapier emerged to keep copies of the same Customer or Invoice in sync across apps, underscoring how entrenched the object paradigm had become. This integration tangle brought with it significant cyber security hazards as sensitive business objects now traversed multiple third-party systems with varying security standards.

5. Stagnation

Despite exponential advances in compute—imagine today's EPYC processors in the hands of 1990s developers—the underlying modelling technique has barely evolved. If such computing power had been available earlier, the unbundling of monolithic applications into smaller distributed parts might not have been the immediate need in business software. Yet functionally, we have made little progress in innovating how software is created to advance human work. Every business software remains fundamentally a set of objects with CRUD operations, wrapped in ever-thicker integration layers that struggle to keep data consistent across your computers and other people's computers.

Section II – Rethinking Business Software as Finite Object State Machines

1. FSM Primer

For those unfamiliar with Finite State Machines (FSMs), understanding their fundamental primitives is essential:

• States: Discrete conditions an entity can exist in (e.g., "Draft", "Pending Approval", "Approved")

• Events: Triggers that can cause state changes (e.g., "Submit", "Approve", "Reject")

• Transitions: Mappings from (Current State, Event) to Next State

• Guards: Conditional logic that determines if a transition should occur

• Side-effects: Actions executed during transitions (e.g., notifications, data updates)

The term "Finite" is crucial here—it means the system has a countable, well-defined number of possible states, making the entire system's behavior predictable and verifiable.

2. O for Object

The "O" in FOSM refers to the business entity or Object involved in the work process. Unlike traditional object-oriented thinking where objects are passive data structures manipulated by external functions, in FOSMs, objects become active participants in their own lifecycle.

Consider a "Customer" object: In CRUD systems, it's merely a collection of attributes to be created, read, updated, or deleted. In a FOSM paradigm, this same Customer traverses a well-defined state graph—visiting the store (state change: Prospect → Visitor), submitting support tickets (state change: Customer → SupportRequester), making purchases (state change: Shopper → Buyer), and so on.

Each of these transitions happens through explicit events, making the Customer object's journey through your business processes both visible and governable. The object itself becomes inseparable from its allowable state transitions.

3. FOSM vs CRUD

The fundamental difference between CRUD and FOSM paradigms is one of constraints and intention:

• CRUD treats objects as bags of attributes that can be arbitrarily edited at any time. There's no inherent protocol defining when something can change or which combinations of changes make sense together. An Invoice might go directly from "Draft" to "Paid" without the required intermediate steps, simply because a developer or user edited a status field.

• FOSM requires explicit, allowable transitions between well-defined states. An Invoice can only proceed to "Paid" if it first became "Approved" and then received a "PaymentReceived" event. The transition maps are first-class elements of the system design, not implicit in code scattered throughout the application.

4. Composability & Hierarchical FOSMs

One of the most powerful features of FOSMs is their natural composability. Complex business processes rarely exist in isolation—they nest within each other and communicate across boundaries. FOSMs elegantly model this reality through hierarchical state machines:

• Parent-Child Relationships: A high-level process (e.g., "Order Fulfillment") can contain nested sub-processes ("Payment Processing", "Inventory Management"), each with their own state machines

• Event Bubbling: Events can propagate up the hierarchy, allowing a child state change to potentially trigger transitions in parent states

• Orthogonal Regions: Independent aspects of an object can be modeled as parallel state machines that evolve simultaneously (e.g., an Order's payment status and shipping status)

This composability allows system designers to break down complex workflows into understandable, reusable components without sacrificing the holistic view.

5. Auditability & Governance

Traditional CRUD systems make auditing a retrospective, bolt-on concern. With FOSMs, auditability becomes a natural byproduct of the architecture:

• Immutable Transition Logs: Every state change is recorded as an immutable event with metadata (who, when, why), creating a natural audit trail

• Process Compliance: Because transitions are explicitly defined, policy violations become impossible by design rather than by vigilance

• Root Cause Analysis: When issues arise, investigators can trace the exact sequence of events and decisions that led to the problematic state

• Regulatory Alignment: Many regulated industries (finance, healthcare) already think in terms of allowable state transitions; FOSMs make this explicit in code

These features transform governance from a cost center into a value-generating capability, particularly valuable in environments with high compliance requirements.

6. Runtime Adaptability

In rapidly changing business environments, software must evolve without disruption. FOSMs excel here:

• Hot-Reloadable Definitions: State machine definitions can be updated without redeploying the entire application. New states and transitions can be introduced while the system continues operating.

• Versioned State Maps: Multiple versions of a state machine can coexist, allowing in-flight processes to complete using their original rules while new processes follow updated workflows.

• Migration Capabilities: Objects in one state can be programmatically migrated to compatible states in newer versions of the machine, with appropriate validation.

• Feature Toggles: Specific transitions can be enabled/disabled dynamically based on operational needs or gradual rollout strategies.

This adaptability significantly reduces the change management overhead that plagues traditional systems, where business process changes often require complete redeployments and downtime.

Section III – FOSMs as a Catalyst for Human + AI Collaboration

For decades, the industry struggled to adopt state machine approaches despite their theoretical benefits. The complexity of specifying complete state diagrams, transitions, and guards for real-world business processes seemed insurmountable. However, the emergence of sophisticated AI capabilities has fundamentally changed this calculus. Now, the combination of FOSMs and AI offers a revolutionary paradigm for how humans and machines collaborate in business software.

1. AI-Assisted FOSM Design & Specification

Historically, FOSM-based systems were challenging to implement because of the extensive upfront requirements engineering needed. AI completely transforms this landscape:

• Domain-Specific Knowledge Extraction: LLMs can analyze existing documentation, code, and process descriptions to identify candidate states, events, and transitions

• Conversation-to-Specification: Business stakeholders can have natural language conversations with AI, which then produces formal FOSM specifications

• Automated Verification: AI can simulate thousands of paths through a state machine to identify edge cases, dead-ends, or unreachable states

• Visual Generation: From textual descriptions, AI can generate visual state diagrams that humans can instantly comprehend and refine

This symbiosis makes FOSM design accessible to organizations that previously lacked the specialized expertise required, dramatically lowering the adoption barrier.

2. Bounded Task Collaboration

One of the most powerful aspects of FOSMs is how they create bounded contexts for Human+AI collaboration. Each state in the machine represents a well-defined situation with clear tasks to be completed before transitioning to the next state:

• Clear Division of Labor: States can explicitly indicate whether a human, AI, or combination should handle specific tasks

• Predictable Handoffs: The transition boundaries provide natural synchronization points between human and AI activities

• Quality Gates: Guards can ensure that neither humans nor AI agents can advance a process without meeting defined quality criteria

• Governance Enforcement: Compliance requirements can be encoded directly in the state transition rules, making oversight transparent

This bounded approach prevents the "AI gone rogue" scenario that concerns many organizations, as the machine's actions are always confined to the allowable transitions for the current state.

3. LLM-Driven Transition Suggestions

In traditional workflow systems, users often need extensive training to understand what actions they can take at each step. With FOSMs and AI:

• Contextual Action Recommendations: LLMs can analyze the current state and object properties to suggest the most appropriate next transitions

• Natural Language Prompting: "What can I do with this order now?" can return a prioritized list of valid transitions

• Consequence Explanation: "What happens if I approve this invoice?" triggers AI to simulate the transition and explain downstream effects

• Batch Processing Guidance: "Which of these 50 applications are ready for approval?" leverages the explicit state model to filter and prioritize work

This creates an intuitive interface layer over complex business processes, making expert-level decision-making accessible to all users.

4. Guard Evaluation via AI

Guards are conditions that determine whether a transition can occur. Traditional systems implement these as rigid if-then rules, but AI enables far more sophisticated approaches:

• Unstructured Data Assessment: Guards can evaluate sentiment in customer emails, analyze free-text explanations, or interpret attached documents

• Multimodal Evaluations: Guards can process images ("Is this ID card valid?"), audio ("Is the caller frustrated?"), or video evidence

• Confidence Thresholds: If AI guard evaluation falls below certain confidence levels, the system can automatically route to human review

• Learning from Decisions: Guard implementations can improve over time by observing human decisions in similar situations

These capabilities allow FOSMs to handle processes that previously required human judgment at every step, significantly expanding their applicable domains.

5. Natural-Language Interfaces

The explicit structure of FOSMs creates the perfect foundation for natural language interfaces to business processes:

• State-Aware Questions: "What's blocking this order?" → AI traverses the FOSM to identify the current state and its exit criteria

• Counterfactual Reasoning: "Why wasn't this loan approved?" → AI can trace the path through the state machine and identify which guards prevented progression

• Process Explanations: "How does our refund process work?" → AI can walk through the states and transitions in the relevant FOSM

• Conversational Process Execution: Complex workflows can be advanced through natural conversation rather than form-filling

This democratizes process knowledge, allowing anyone in the organization to understand and interact with complex workflows without specialized training.

6. Autonomous Process Optimisation & Organizational Memory

Beyond just executing processes, AI can help organizations improve their processes while preserving and enhancing institutional knowledge:

• Bottleneck Identification: Reinforcement Learning (RL) agents—AI systems that learn through trial and error with feedback—can analyze transition time distributions to identify process blockages

• A/B Testing Transitions: Different guard implementations or transition paths can be tested against business KPIs

• Simulation-Based Optimization: AI can simulate thousands of process variations to recommend optimal state machine designs

• Continuous Adaptation: As business conditions change, AI can suggest FOSM modifications to maintain optimal performance

• Organizational Tacit Knowledge: The state machine data becomes the organization's "brain"—capturing not just what processes exist, but how they evolve, where they get stuck, and what constitutes successful paths

This approach transforms FOSMs into living repositories of institutional knowledge, where the cumulative wisdom of the organization becomes encoded in the transition patterns, guard conditions, and historical paths. Unlike traditional process documentation that quickly becomes outdated, this knowledge continuously evolves alongside the business. Process optimization shifts from periodic, consultant-led initiatives to continuous, data-driven evolution grounded in the organization's actual operations.

7. Safety & Alignment

The explicit nature of FOSMs provides guard rails for AI autonomy:

• Constrained Action Space: AI agents can only perform actions explicitly allowed by the current state's available transitions

• Verifiable Behavior: The state machine itself serves as a formal specification against which AI behavior can be verified

• Transparent Decision Boundaries: Guards make explicit exactly when an AI can and cannot take specific actions

• Human Approval States: Critical transitions can require explicit human approval, creating natural checkpoints in autonomous processes

These properties make FOSMs an ideal architecture for deploying AI in regulated, high-stakes environments where unconstrained AI action would be unacceptable.

Section IV – Challenges and Limitations

Despite their advantages, implementing FOSMs is not without challenges:

State Explosion Problem

As systems grow in complexity, the number of states and transitions can grow exponentially. A FOSM with numerous attributes, guards, and nested hierarchies can become unwieldy to design and maintain.

Mitigation strategies include:

• Hierarchical composition to encapsulate complexity

• AI-assisted modeling to automatically identify optimal state groupings

• Pattern-based design using proven templates for common business scenarios

Human-AI Collaboration Boundaries

Defining clear boundaries between human and AI responsibilities requires careful design:

• Ambiguity in guard evaluation: When AI evaluates unstructured data for transitions, confidence thresholds must be established

• Over-reliance on AI suggestions: Users may develop automation bias, accepting AI suggestions without critical evaluation

• Skill degradation: As AI handles more decisions, human understanding of processes may diminish

Organizations must invest in training that reinforces human judgment while leveraging AI capabilities.

Legacy Integration Challenges

Few organizations have the luxury of a greenfield implementation:

• Mapping existing data models to state-based representations

• Incremental adoption strategies to gradually transition from CRUD

• Dual-paradigm operation during transition periods

Implementation Effort

The upfront design effort for FOSM can appear daunting:

• Explicit state modeling requires more initial thought than implicit CRUD approaches

• Cultural resistance to changing development paradigms

• Tooling immaturity compared to decades-old CRUD frameworks

However, this initial investment is offset by reduced maintenance costs, fewer bugs, and more predictable system behavior over the software's lifetime.

Conclusion

The transformation of business software from simple object manipulation to intelligent process collaboration represents one of the most significant opportunities in enterprise computing. For decades, we've accepted the limitations of the CRUD paradigm—its implicit workflows, scattered business logic, and poor fit for modeling real-world business processes—as necessary tradeoffs for developer productivity and database efficiency.

Finite Object State Machines offer a way forward that is both theoretically sound and newly practical. By making the states, transitions, and guards of business objects explicit, FOSMs create a natural framework for defining how humans and AI can collaborate within bounded contexts. This explicitness brings transparency, compliance, and adaptability—qualities essential for regulated industries but beneficial for any complex business operation.

The emergence of AI has eliminated the historical barriers to FOSM adoption. The once-prohibitive cost of specifying state machines is now dramatically reduced through AI-assisted design and specification. Moreover, the bounded context that FOSMs provide solves one of the most challenging problems in AI deployment: ensuring that autonomous systems operate within well-defined guardrails.

As organizations increasingly rely on the complementary capabilities of humans and AI, the need for a structured framework to orchestrate this collaboration becomes critical. FOSMs provide this structure, allowing us to move beyond the simplistic object manipulation paradigm that has dominated business software for the past three decades.

The future of enterprise software lies not in merely digitizing existing processes, but in fundamentally rethinking how humans and machines collaborate to achieve business outcomes. FOSMs provide the architectural foundation for this future—one where compliance is built-in, processes continuously improve, and human creativity is amplified rather than constrained by the software we use.

References

• Avnur, A. (2015). A Finite State Machine Model for Requirements Engineering. Requirements Engineering Magazine. Link

• Chen, Y., & Liu, J. (2018). Business Objects - A New Business Process Modeling Approach. SpringerLink. Link

• Clarke, E. M., & Wing, J. M. (2001). Progress on the State Explosion Problem in Model Checking. ResearchGate. Link

• David, I., & Harel, D. (1987). Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, 8(3), 231-274.

• Hamza, M. (2023). Human AI Collaboration in Software Engineering: Lessons Learned from a Hands On Workshop. arXiv. Link

• Kumar, R. (2015). Finite State Machine, Case study of Air conditioning system. ResearchGate. Link

• Steiner, R., & Masiero, P. (2013). Managing SPL Variabilities in UAV Simulink Models with Pure::variants and Hephaestus. CLEI Electronic Journal, 16(1).

• Wagner, G. (2019). Designing State Machines with XState. Link