The Surfer Position
There is a position on the rising wave of AI capability that gets stronger as the wave gets larger. Not in spite of the wave — because of it. A long look at the role of the human Possibility Space Engineer in an era of rising AI capability.
The Surfer Position
There is a position on the rising wave of AI capability that gets stronger as the wave gets larger. Not in spite of the wave — because of it. It is the position of the human who shapes how AI is deployed inside a company, who stewards what AI becomes as the company grows, and who finds the optimal paths through the possibility space that is newly opening as old constraints dissolve.
We call it the Possibility Space Engineer.
This essay is a long look at that position — what it is, why it exists, why it compounds as the substrate around it evolves, and what gets built when someone takes the position seriously. It is also an argument for treating the craft as a craft — a specific discipline with its own analytical lens, its own working vocabulary, and its own ways of being present inside an organization.
The argument runs in seven movements. Phase space — what it means to see a company as a point in a topology of possible futures, mappable as trajectories that can be analyzed and chosen between. The Possibility Collapse — why the question you ask at the most fundamental level can compress a century of downstream work into a single moment. The Strange Attractor Drift — why systems left alone, including AI systems calibrated brilliantly in isolation, lose value as the world changes underneath them, and why the human navigator at the center of those systems is what keeps value compounding. Friction as topology — the recognition that companies have a structure of interlocking frictions, and that the structure is what a Possibility Space Engineer maps before building. What gets built — six specimens of the craft, told honestly. The Compound Loop — why the partnership that stays with the system after launch is what turns an artifact into an asset. And the wave itself — what the current substrate of AI capability actually looks like in 2026, and why the person who rides it well rises with it as the wave grows.
The essay is long because the position is real and the argument for it benefits from being made carefully. Ten minutes of reading for anything that will shape a year of a company's operations is reasonable.
I. Phase Space
The first question is what possibility space is — and the answer changes what it means to build software for a business.
In dynamical-systems theory — the lens physicists and mathematicians use to analyze any complex system that evolves over time — a system's state at any moment can be represented as a point in a high-dimensional space called phase space. Every variable the system can take on — temperature, position, velocity, concentration, configuration — is an axis. The system's current state is a point with coordinates on each axis. As the system evolves, the point moves. It traces out a trajectory through phase space.
Trajectories vary in value. Some lead to outcomes measurably more valuable than others — more stable, more productive, more aligned with what the system could become at its best. The work of understanding any complex system is, at root, the work of understanding which trajectories are available from a given starting point and which of them are worth taking.
Companies are dynamical systems. They have state — the configuration of their people, processes, data, capital, vendor relationships, client relationships, reputation, product maturity, market position, internal culture, technical substrate. They evolve through time. They face choices at every moment that determine which trajectories through the larger phase space become available next.
Most problem-solving in business happens at the surface level. A team is spending ten hours a week reconciling spreadsheets; someone buys a reconciliation tool. A customer support queue is growing faster than the team can respond; someone hires another agent. A CEO wants to be more AI-forward; someone kicks off a pilot. These responses are all real attempts to move the system forward, and they often produce real local improvement. They operate at the visible altitude, where the structural source that produced the friction stays untouched.
Possibility Space Engineering operates at the generating altitude. It treats the specific friction as signal — a legitimate report from the system about something structurally true about the current state — and then asks what trajectory through phase space would dissolve the structural condition producing the friction. The ten hours of reconciliation is a symptom of two systems exchanging data in a mismatched format, which is a symptom of a vendor selection made before the integration was thought through, which is a symptom of a procurement process where integration review still lives outside the decision. The support queue is a symptom of a product with unclear states, which is a symptom of a design language that conflates outcomes with configurations. The AI pilot is a symptom of curiosity reaching for craft — wanting AI before knowing what AI-shaped leverage looks like for the specific operational reality.
Each of these observations opens a different trajectory. One trajectory patches the reconciliation tool. A different trajectory redesigns the procurement process so that integration review is built into the decision from the start. One trajectory adds a support agent. A different trajectory rebuilds the product's state model so that the support queue shrinks structurally because the product's state model resolves the ambiguity that was generating the questions. One trajectory buys an AI tool. A different trajectory builds the team's capability to diagnose their own AI-shaped opportunities and compose the systems that exploit them.
Surface-level trajectories have their place; sometimes the patch is the right move. The discipline we are naming is the ability to see above the surface level — to analyze at the altitude where the friction is generated, where the structural source actually lives. That altitude is specific, learnable, and valuable. A Possibility Space Engineer lives at it by default. The craft is the practice of looking at the system this way, mapping the topology of trajectories available from the current state, and then choosing and building deliberately.
The physics of dynamical systems makes specific claims about working at this altitude. Trajectories through phase space vary in accessibility. Some depend on initial conditions the system has already left behind. Some are available only through a sequence of intermediate states the system has to pass through to reach them. Some require external energy — investment, effort, commitment — beyond what the system currently has on hand. A good phase-space analysis identifies the best trajectory from here — taking into account the gradients, the attractors, and the energy budget that bound which states are actually accessible from the current position. This is what Possibility Space Engineering looks like in practice: a concrete account of how a specific company moves from its current state to a materially better state through a sequence of buildable, steerable changes.
II. The Possibility Collapse
The most underappreciated consequence of dynamical-systems thinking is what happens when the question you are asking is at a fundamentally different altitude than the question the field is asking. Most of the time, this is eccentric. Occasionally, it compresses a century of work into a single moment. We call this the Possibility Collapse.
Consider Alexander Graham Bell in his Boston workshop in 1875. He was pursuing a specific question: could sound waves be converted into modulated electrical currents, transmitted through copper wire, and reconverted back into sound waves at the other end? This question had a clear answer; within a year, the answer was yes, and the telephone emerged from that answer. A century of telephony followed. Copper infrastructure spanned continents. Exchanges, switchboards, area codes, long-distance tariffs, all of it — a vast edifice built on the foundation of Bell's specific question and its specific answer.
Now imagine the counterfactual. Imagine that Bell, or someone near him, had asked a slightly different question: could sound waves be converted into photons and transmitted through the air? This is a question at a different altitude. Bell's question was about a specific transduction pathway — sound to electricity to sound. The counterfactual question is about the fundamental physics of information transmission, unbound from a specific medium. If Bell had asked the counterfactual question and pursued it to its conclusion, wireless communication would have appeared in the 1870s alongside the wired telephone — as a direct answer to the original question, with the century of wireless maturation collapsed into the initial discovery. Radio, cellular, satellite — all downstream of the same transducer question, once asked at the higher altitude.
Bell asked the wired question — the question the 1875 state of tooling made most tractable. Electromagnetic wave generation was more speculative in Bell's era; Heinrich Hertz hadn't yet demonstrated the radio waves that would make the wireless answer obvious. The counterfactual serves a specific purpose. It illustrates what changes about a century of downstream work when the question is asked at a different altitude.
A question asked at the wrong altitude produces answers at the same altitude. A century of wired telephony is the answer to a wired question. The century stands on its own; the wired answer is a real answer, genuinely valuable, and the infrastructure it produced was load-bearing for everything that came next. The wired century was also, in a specific sense, the long way around. The wireless question, had it been the question, would have made the century a footnote. The altitude of the question determined the altitude of what came after it.
This matters for our argument because the questions businesses are currently asking about AI are mostly wired questions. Can we get a chatbot to answer customer service tickets? is a wired question. Can we get an agent to draft proposals? is a wired question. Can we use AI to summarize our internal documents? is a wired question. Each of these questions is well-formed. Each has a clear answer, and the answers are usually worth the investment. But each is operating at the altitude where AI is a tool applied to an existing process. The process is the assumption. The AI is the modification. The system after the modification is still the same system it was before, incrementally better. This is the wired century, arriving on schedule.
The higher-altitude question is different. The higher-altitude question is: given what AI can now do, what would our company's entire operating system look like if we designed it from the ground up for this substrate? This is the photon question. It starts from the fundamental physics — what work can now be done, by whom or what, at what cost, at what latency, with what fidelity — and asks what configuration of humans and systems produces the most valuable outcome given those new physics. The answer is usually a system that reconfigures who does what kind of thinking across the whole operation — built on different assumptions about where human judgment compounds and where AI capability carries the load.
The companies asking the photon question right now are building the operating systems of the next decade. The companies asking the wired questions are buying tools that will be obsolete within eighteen months. Both are investing in AI. One is investing in trajectories through phase space that compound over years; the other is investing in local improvements that operate within the trajectory the company was already on. Both are honest work. Both are real.
The Possibility Space Engineer's job is to make the photon question askable for a specific company, in a specific industry, with specific operational realities. The craft maps the company's phase space from the inside, finds the high-altitude questions tractable given the company's specific constraints, and then engineers the systems that navigate toward the answers. This is what Possibility Space Engineering means as a practical discipline. It is concrete work — the difference between a catering company that runs a five-person ops team for ten years with a $100K event-management tool, and a catering company that runs a two-person ops team indefinitely with a custom operating system where the AI carries the coordination load and the humans carry the judgment load. Same company. Same market. Different altitude of the original question.
The dynamical-systems lens is what a Possibility Space Engineer brings into the room. From inside the work, phase space appears as a flat list of current pains; from outside, it appears as a topology of available trajectories. The lens is the offer. Once it is in the room, the photon question becomes askable for the specific business in the specific industry with the specific operational realities. The Possibility Space Engineer helps the company find and ask the photon question their specific position lets them answer, then builds the system that makes the answer real.
III. Why Human Navigation Compounds
A reasonable question arises at this point. If AI is getting more capable, and the analytical lens we are proposing can be formalized and taught, why is the role we are describing a human role? Why is there a human Possibility Space Engineer at the center of this picture, alongside the agents and analyzers? The question is fair, and the answer is specific. It comes down to a property of the substrate that most discussions of AI capability elide.
Systems left alone drift. This is a property of any calibrated system operating in a world that continues to change after the calibration was performed — broader than AI, intrinsic to calibration itself. The agent you build today to automate a workflow is tuned to the tooling, the data shapes, the team vocabulary, the vendor integrations, and the business realities of today. Next quarter, one of your vendors ships a new API that supersedes your integration. A new model is released that would make a different architectural choice obviously superior to the one you made. A new regulation changes what data can cross which boundary. Your team's vocabulary shifts because a new hire brought in a framework that gets adopted. Your clients' expectations about response quality rise because they used a competitor's better product.
Any one of these changes, by itself, is minor. But the substrate of a company is composed of thousands of these calibration points, all of them drifting at different rates in different directions. In dynamical-systems terms, the attractor the agent was tuned to — the specific region of state-space where the agent performs optimally — is itself moving. When the agent is left to run, the distance between the attractor and the agent's actual configuration grows over time. Eventually, the agent is optimizing for a state of the world that has moved on. This is the Strange Attractor Drift — the observation that agents operating in open systems require continuous reshaping to stay aligned to value as the substrate beneath them shifts.
The complete picture includes the navigator. A human in the loop, continuously reshaping the system in response to what the substrate now allows and what the domain now requires, experiences an accumulation curve. The navigator sees the vendor ship a new API and reshapes the integration the next week. They see a new model release and re-architect the agent to exploit the new capability. They see the team's vocabulary shift and update the system's knowledge base to match. Every change in the substrate becomes information that feeds forward into the next version of the system. The Strange Attractor Drift is the mechanism by which the navigator-in-the-loop system compounds. Drift produces signal; signal produces reshaping; reshaping produces capability beyond the prior configuration.
This is the pattern that makes the Possibility Space Engineer durable. The argument is structural. In an open system where the substrate evolves faster than any calibration can hold steady, the role that compounds is the navigator's — the human who reads the drift, understands what the new substrate makes possible, and reshapes the deployed systems accordingly. The deeper AI gets, the more capability the substrate accumulates, and the more valuable the navigator becomes. The wave grows; the surfer rises with it.
This is why we keep returning to the word "partnership" when describing MainThread's engagement model. A partnership is a commitment to stay in the navigator role over time. The partnership captures the trajectory the system traces through the substrate's evolution; a one-off build captures a single moment of substrate history as code. The partnership is the commitment that someone is continuously watching the substrate, continuously reshaping the system, continuously naming the new frictions that emerge and dissolving them before they compound. The system that comes out of a partnership is a living artifact — built once and then evolved weekly, monthly, quarterly, indefinitely.
The structure of how AI investments are funded shapes whether they hold value. Capital-expenditure framing front-loads the value at launch; partnership framing back-loads it into the engagement that keeps the system alive. A well-navigated AI system at month twelve is measurably more capable than at launch — same code, same architecture, different trajectory through the substrate's evolution. The difference between capex and partnership is the difference between decay and compounding.
The practical consequence for anyone considering bringing AI into their company is that the question is who will navigate what we build, continuously, indefinitely? The build compounds when the answer is specific: a dedicated navigator in the loop, tied into the substrate's evolution, reshaping the system as the substrate shifts. The navigator is the structural prerequisite for AI investments to hold value over time. This is the physics, observed at scale across the work.
The Possibility Space Engineer is the navigator. The work is continuous. The value compounds. The deeper AI gets, the more this role matters.
IV. Friction as Topology
The word friction keeps appearing in this essay, and it is doing specific work. In most business writing, friction is a point phenomenon — the specific thing that is slow, or broken, or painful, named as a single noun. "The reporting process has friction." "There's friction in the handoff between sales and implementation." "We hit friction on the compliance review." Each of these sentences names a spot and implies that removing the spot would remove the problem.
This framing captures the surface; the topology lives one layer deeper. Companies have friction topologies — interlocking structures of slowness and ambiguity and effort that connect to each other in ways the surface naming leaves out of view. The reporting process has friction because the data lives in three systems that don't share a primary key. The handoff between sales and implementation has friction because the sales conversation captures outcomes that the implementation team has no format to receive. The compliance review has friction because the specific operational decisions the team makes have no documented requirements yet. Each of these is a point friction; each is also structural; and each connects to the others through how the company actually operates.
A Possibility Space Engineer approaches any new engagement by mapping the topology first. The work is closer to what a topographer does when reading a landscape — walking the ground, noting the ridgelines and the valleys, understanding which features flow into which, and producing a map that captures both the individual features and the relationships between them. The reporting system is a valley; the sales-to-implementation handoff is a ridge connecting two plateaus; the compliance review is a choke point in a pass that everyone has to go through. Each feature is real on its own, and the topology is what tells you where the leverage is.
Point-fixes on a friction topology often produce zero net improvement, and sometimes shift the load downstream rather than dissolving it. Consider a team that identifies a manual process (reporting, say), automates it (reporting tool), and then discovers that the next downstream team has to renegotiate its workflow because the automated output arrives at different latency and format than what they had been receiving. The automation worked locally. The friction migrated downstream — because the topology was understood only as point-frictions when the fix was made, the fix addressed a symptom that was load-bearing for the adjacent processes.
Dissolving the friction requires looking at the full topology before shipping anything. The reporting system is a symptom of a data architecture that wants reconciliation. The handoff is a symptom of a language gap between two functions that wants a shared vocabulary. The compliance review is a symptom of operational decisions that want documented requirements. Addressing each of those root-level conditions produces a system where the original point frictions resolve through the structural change rather than through individual patches. The result is a system structurally different from the one the company had before — and the difference reveals capability the original framing never reached for.
The busy work that people dread on Monday mornings is signal — the visible edge of a deeper topology. A payroll administrator spending three hours every week manually reconciling timesheets is reporting that the timecard-capture system, the employee master record, the PTO tracker, and the payroll provider live in four ungoverned silos. The three hours are the report. A catering operations manager running events out of a fifteen-tab spreadsheet plus a group chat plus sticky notes on the warehouse wall is reporting that the operational domain runs on improvised coordination where the work calls for an operating system shaped to the actual workflows. An aircraft parts distributor whose inventory search requires knowledge living in one senior employee's head is reporting that the knowledge infrastructure lives inside one biography where it could live as substrate the team shares.
These are all real examples from MainThread engagements — the payroll case is generic across many of our partnership buyers, the catering case is TWE Events, the parts distributor case is Horizon Parts. In each case, the point friction was how the engagement started. The Possibility Map we produced for each showed that the point friction was a proxy for a structural condition, and the structural condition was what we built toward. The systems we shipped, in every case, looked different from the original ask — because the topology was asking for an operating system, and the operating system is what we shipped.
Friction topologies compound over time. A company that has been operating for ten years has, in general, ten years of accumulated topology — each year's fix moving the load to the next adjacent surface, blind to where it would land. This accumulation is why older companies often feel "heavier" than newer ones. The topology is so dense that local AI additions get absorbed into the existing friction. The way to work with these topologies is to find the highest-leverage structural condition that, addressed, dissolves the largest adjacent region of the topology. This is phase-space work. It is the core activity of Possibility Space Engineering.
V. What Gets Built
We have been describing a discipline. Now we describe the artifacts. A craft has to produce things, and the things have to be real, and the realness is what keeps the discipline honest. This section is a look at three artifacts MainThread has built, each of them a specific answer to a specific company's phase-space situation. We tell them honestly, with the names of the things and the specifics of the mechanisms, so that what we mean by we engineer possibility space lands with the concrete weight of the work itself.
Genesis — Personal Market Intelligence as a Platform
Genesis is a full-stack software platform for one specific kind of work: navigating one's career in a market where the shape of the right role lives outside what conventional job-board search can surface. A job board is a static inventory. A career market is a dynamical system. The difference, as a practical matter for a mid-to-senior candidate, is the difference between browsing ten thousand roles where the right three are buried and receiving a curated intelligence briefing each week that surfaces the three roles that match your trajectory, with the reasoning for each and the market context around them.
The Possibility Map we drew when starting Genesis identified the phase-space problem precisely. The market for any given candidate's actual target roles uses, on average, twenty to one hundred different job titles for what is essentially the same work. Standard job-board search is title-matching, which means it finds at most five to twenty percent of the relevant market. The remaining eighty to ninety-five percent is invisible to the search because the candidate and the market are using different vocabularies for the same thing. The friction lives in the search primitive — calibrated to title-matching, when the work being searched for uses twenty to one hundred different titles for the same role. We needed a different primitive.
The primitive we built is a harvesting pipeline that runs around each candidate's trajectory rather than around a static title set. Every candidate gets a bespoke configuration — the companies they'd want to work at, the title clusters they'd consider, the seniority bands, the geographic and remote preferences, the industry constraints, the specific things they've said no to in past searches. The pipeline crawls over six thousand company career pages, applies candidate-specific ranking, and produces an intelligence briefing at the cadence the candidate's tier warrants. The briefing is analyst-grade synthesis: prioritized roles with reasoning, the compensation landscape for the candidate's niche, named patterns we've observed in their market across multiple briefings (a sudden hiring wave at a specific pharmaceutical company, a compensation anomaly in the senior non-executive tier of a specific geography, a structural trap where the job title reads as leadership but the actual function is specialist IC work), and a positioning recommendation that integrates everything.
Underneath the product surface, the infrastructure is specific. Next.js 16 with App Router and Server Components on Vercel, Supabase for the data layer, Voyage AI 1024-dimensional embeddings for semantic search across jobs and messages and artifacts in a shared embedding space, durable agent substrate via Vercel's Workflow DevKit for the long-running intelligence pipelines that produce each briefing, pgmq for queue-based asynchronous processing, pg_cron for the scheduled lifecycle operations, private Broadcast for 6ms realtime messaging between operator and candidate, and a named-pattern data model that lets observations accumulate evidence across multiple briefings into first-class artifacts with lifecycles (emerging, active, sunset) and canonical instance references. Forty-five row-level security policies. Nine circuit architectures running in parallel. An intelligence loop that closes — candidate preferences are captured, processed, fed back into the ranking, and surface as observable patterns across the pipeline.
This is what we mean by Intelligence Platform as one of the Five Archetypes. The product surface looks like software; the engine underneath is a persistent agent layer paired with human operator judgment. The AI is the substrate that makes the feature possible. The operator — Dave — designs the harvest, reviews the briefings, names the patterns, and shapes the judgment that gets published to each candidate. The system compounds as each candidate's harvest teaches the next. Genesis in week 52 is materially more capable than Genesis in week 1, because 52 weeks of navigator-in-the-loop reshaping have compounded into the current substrate.
Genesis is also the artifact by which MainThread's own methodology became visible to us. Building it taught us what Possibility Space Engineering actually requires when the domain is information-dense and the users are individuals rather than organizations. The Longitudinal Gap, the Harvest Lag Trap, the Comp Floor Illusion, the Functional-Ops Masquerade — these are named patterns that emerged from Genesis operations and became part of the studio's working vocabulary. The platform is both product and research instrument. This is the pattern we find repeatedly when Possibility Space Engineering is done well: the system you build to serve one kind of user becomes the method by which you learn what to build next.
TWE Events — An Operating System for a Catering Company
TWE Events is a catering operator running events in the ten-thousand-dollar-and-up range — full-service productions with logistics, staffing, equipment, and day-of coordination. They had been operating for years out of spreadsheets, group chats, paper checklists, and the collective memory of the team. The business worked, because the team was good and cared about the work, but every event was an act of controlled chaos, and the chaos put a ceiling on the team's capacity.
The Possibility Map here addressed a specific question: whether the right trajectory was to adopt a standard tool and reshape the business to fit the tool, or to build an operating system shaped to the business as it actually operated. Any standard event-management SaaS would theoretically help; the question was whether "theoretical help" was the trajectory worth taking. Standard event-management tools are designed around a canonical event workflow: venue selection, guest list, timeline, vendor coordination, day-of checklist. TWE's workflow shared some of these stages, but their actual pain points were specific — warehouse coordination for equipment inventory moving between events, logistics for equipment arriving from multiple vendors at a venue on the same day, staff role assignment for a mix of full-time and contracted employees with different skill profiles, real-time coordination on event day between the ops lead and the ground team via the fastest communication channel the team already used. These are specific problems — the kind that warrant systems shaped to them. A standard tool would handle perhaps seventy percent of them adequately and would impose its own assumptions on the remaining thirty percent. The engagement would shape itself around writing workarounds for the assumption mismatch.
The trajectory we chose was the operating-system path. We built a platform shaped to TWE's actual processes. Event creation starts from templates that match TWE's common event types. Equipment inventory lives in a warehouse module that tracks the physical location and availability of every item across events and time. Staff assignment uses TWE's actual role vocabulary. Day-of coordination runs on mobile surfaces optimized for the specific communication patterns the ops team uses at the venue. The system learns TWE's language. Future expansion includes payroll integration tied to the staff-assignment data, vendor invoice reconciliation tied to the equipment receipts, and a reporting layer that the founder can look at once a week to understand margin health across the current event portfolio.
This is what we mean by Operating System as a framing for what software can become for a company. An off-the-shelf tool is a product the company integrates. An operating system is the substrate the company runs on. The first is acquired; the second is constructed. The difference shows up in every decision the system has to accommodate for the life of the business. A company running on an operating system shaped to its actual operations can add new event types, new staffing models, new vendor relationships, new logistics patterns as the business grows — and the system adapts to each addition because the substrate is pliable. The operating-system path is more expensive up front; it is dramatically cheaper over the life of the business.
TWE Events is also, for the argument of this essay, an illustration of what the photon question looks like when answered for a specific operator. The wired question, for TWE, was: what event-management software should we adopt? The photon question was: what operating system would let our three-person ops team run the business indefinitely without adding ops headcount, even as we scale the number and complexity of events? The answer to the wired question would be a decision between three or four standard tools. The answer to the photon question is a built system that fundamentally changes the ops-to-event-count ratio — operational leverage the team carries forward as the business grows.
Job Forges — The Natural Language Agent Application in Production
Job Forges are the studio's longest-standing expression of a specific pattern we call the Natural Language Agent Application, or NLAA. The pattern is simple to describe but hard to internalize: you build a natural-language workspace where a human and an AI partner work together on a specific domain over time, and the workspace itself — its accumulated skills, knowledge, tools, and conventions — becomes the product. A Job Forge is a persistent environment where one candidate and one AI partner pursue the candidate's specific job search with increasing calibration over time.
Each Job Forge is its own repository. Inside the repository is a CLAUDE.md file — the natural-language operating system that defines the identity of the forge, the candidate's specific target roles, the harvesting configuration, the evaluation criteria, the vocabularies the candidate uses, the companies that matter and the companies to skip, the signal documents that capture the candidate's experience in forms the AI partner can reference. The forge contains a set of skills — modular natural-language instructions that reshape the AI's probability space for specific operational modes (harvesting, triage, briefing authorship, application forge). The forge contains knowledge — accumulated observations, prior briefings, notes from interviews, reflections on what compounded and what stalled. And the forge contains tools — the Python scripts, the board interfaces, the database schemas, the source-pool materials that make the environment functionally capable.
What makes this a distinct pattern is that the forge is alive. Every session the candidate runs in the forge, the forge accumulates capability. A new skill crystallizes out of three sessions of doing the same kind of work. A new knowledge document captures an observation worth preserving. A new script automates what had been a manual pattern. The forge in week 26 is materially more capable than the forge in week 1 because the candidate and the AI partner together build the forge through use. The work and the development of the forge are the same activity.
We maintain three active Job Forges at this writing — Christy, Norbert, and Katie — plus Dave's own Cowork forge which is the research instrument for the pattern itself. Each forge looks different because each candidate is different. Christy's forge is tuned to marketing-director roles in specific industries including equine and pharma; Norbert's is tuned to senior video editor and creative director roles across content production and post-production; Katie's is tuned to a different cluster again. The forges share the same substrate — the NLAA pattern, the harvesting infrastructure, the intelligence briefing engine — but the content of each forge is specific to the candidate whose career it is pursuing. This is what we mean by systems shaped to the shape of your work. The shape is the work itself, captured as a configuration, evolved through use.
The NLAA pattern extends beyond career search. It works for any domain where a human and an AI partner benefit from a persistent workspace that accumulates capability over time. Research operations. Content operations. Investment research. Legal case management. Regulatory analysis. Sales account management. Any domain where the work is navigational — where the right next action depends on context accumulated across many prior actions — is a candidate for an NLAA. MainThread builds NLAAs for specific situations where the partnership-over-time pattern produces more value than the transaction-per-instance pattern would.
The Common Thread
Three projects, three different archetypes, three different domains. Genesis is an Intelligence Platform. TWE Events is an Operating System. Job Forges are NLAAs. Each is its own answer to its own question; the discipline underneath each is one discipline. We started each engagement by mapping the friction topology. We identified the photon question that was tractable for the specific company's phase-space position. We engineered the system that made the photon question's answer real. We stayed in partnership to evolve the system as the substrate shifted underneath it. This is the craft. It looks different from the outside depending on the artifact; it is the same from the inside every time.
The portfolio is larger than these three. Horizon Parts is an intelligence and sourcing platform for aircraft parts distribution — a regulated industry with thousands of SKUs across multiple suppliers, where the search primitive has to understand regulatory constraints and cross-supplier availability simultaneously. Zoning Signal is a regulatory intelligence harvester that turns dense municipal zoning frameworks into development opportunity maps — the Decoder archetype applied to the specific domain of municipal regulation, extensible to any dense-corpus domain where navigability would unlock value that is currently invisible. Arena is a social competition platform for structured game nights — brackets, teams, scoring, real-time state, multiple formats — an expression of the same craft applied to a lighter domain. Each is a different expression of the one craft.
And beyond shipped platforms, the expressions extend further: custom internal tools for operations teams, multi-step automations connecting existing SaaS systems through platforms like Make and n8n and Zapier when that's the right substrate, AI agent orchestrations built with LangGraph and CrewAI and Mastra and Anthropic's skills framework composed per problem, embedded AI leadership for growing companies bringing the Director-of-AI function in on retainer, coaching engagements that build a team's own capability to do this work going forward. Same craft. Many expressions.
VI. The Compound Loop
The part of this argument that most matters lives after launch. Every system we ship is designed to compound the longer you use it — and the compounding is what stewardship makes possible. At deployment, the technology works and the capability is there. The substrate then shifts. The partnership keeps the system shifting with it; every change in the substrate becomes new capability the system absorbs.
The structure of the engagement is what makes the difference. Capital-expenditure framing — fund, ship, amortize, move on — releases the system into substrate evolution with no one in the navigator role. Partnership framing keeps the navigator continuously present. The partnership is the mechanism by which the investment compounds.
At MainThread we have a structural commitment that we call the Compound Loop — a partnership model designed to capture the compounding the system produces over time. It has three tiers, lightly named. At the Substrate tier, we keep the technical foundation current: framework updates, model tier refreshes, integration migrations, dependency churn, security patches. At the Domain tier, we keep the knowledge current: context updates, skill refinements, domain-specific reshaping as the client's market evolves. At the Evolution tier, we keep the system becoming: new capabilities added, new primitives integrated as they ship from the ecosystem, new archetype extensions layered in, compound capability grown through use. Most engagements start at Substrate and grow into Domain or Evolution as the partnership deepens and the system's value trajectory becomes visible.
The practical experience of a Compound Loop partnership is undramatic. The system gets materially better week by week, in small increments that accumulate. A new vendor API ships; we integrate it next week. A new model is released; we benchmark it against the current deployment and swap when the swap is clearly better. A pattern emerges in the client's usage that suggests a new skill or a new surface; we build it over the next few weeks. By month twelve, the system is meaningfully different from the one we shipped at launch because we navigated week by week. The client's own experience is that the system keeps feeling current — the quiet alignment of a system being continuously tuned to the substrate it lives inside.
The Compound Loop is also the mechanism by which MainThread itself learns. Every navigation we perform on a deployed system teaches us something about how the substrate is evolving, what integration patterns are becoming load-bearing, what architectural choices are aging well, and which patterns want refactoring. This learning flows back into the studio's craft. A pattern that emerges across three client deployments becomes part of our working vocabulary; a structural pattern we encounter in one engagement informs the Possibility Map we draw for the next. The partnership is how the studio compounds alongside each client. This is the literal structure of how we have gotten better at this work over the last several years, and how we expect to continue getting better for the foreseeable future.
One of the questions we are often asked is whether this partnership model scales. The honest answer: it scales by depth. MainThread operates as a small practice firm with a small number of deep partnerships running concurrently. What we scale is the capability of each partnership; the number stays small by design. We grow by taking on partnerships that warrant the studio's attention and produce work we are genuinely excited to do — slowly, deliberately, the right trade for the kind of work we do. If you are looking for a partnership that stays inside your operation and compounds over years, we are worth a conversation.
VII. The Wave, Specifically
The Surfer metaphor is doing specific work. There is a specific wave, the position we are describing is an actual position on that wave, and the reason the position compounds with the wave's growth is that the wave's growth actually increases the capability available to the navigator. This section is a brief, concrete look at what the wave is in 2026 — the primitives that have matured, the substrate that has consolidated, and what this state makes newly possible.
Start with the agent substrate. Two years ago, building an agent that could run for hours without supervision was a serious engineering challenge. You had to manage your own state persistence, handle restarts and retries manually, deal with timeouts imposed by the hosting substrate, orchestrate tool calls across different latency regimes, and accept that any production deployment would require continuous babysitting. Today, Vercel's Workflow DevKit provides durable agent execution as a language-level primitive. A function marked "use workflow" can run for hours or days, survive crashes and deployments, pause for human input and resume exactly where it left off, and replay from any checkpoint for debugging. The same substrate provides ephemeral Firecracker microVMs for agents that need to browse the live web or execute untrusted code safely. The mechanical challenges of building durable agents have collapsed from being the entire engineering effort to being a language feature.
Continue with model orchestration. Two years ago, multi-model routing — using the best model for each task shape, failing over when a provider had an outage, attributing costs per feature — was a custom engineering project in every company that cared. Today, Vercel's AI Gateway provides unified routing across 100+ models from all major providers, zero markup on tokens, automatic provider failover, per-tag cost attribution, budget alerts, hard spending limits, response caching, and audit logging. Every team that ships AI now has enterprise-grade observability and cost governance built in by default.
Continue with chat-platform deployment. Two years ago, deploying a conversational agent to where a team actually worked — Slack, Teams, Discord, Google Chat — was three or four separate integration projects. Today, Vercel's Chat SDK ships unified adapters for all of them, plus Telegram, GitHub, Linear, WhatsApp, and more. One codebase, eight chat platforms. The "embedded operator" pattern we described as an archetype — an Intelligence System living inside the tools a team already uses — went from being a significant engineering undertaking to being a weekend project.
Continue with integration primitives. Two years ago, giving an AI agent access to a company's internal systems meant writing bespoke integrations for each tool. Today, the Model Context Protocol — an open specification with over ten thousand public MCP servers and ninety-seven million monthly SDK downloads as of this writing — has become the de facto standard for AI tool integration, adopted across the major model providers and under Linux Foundation governance. An agent you build today can plug into existing MCP servers for the major SaaS tools a company runs on, and you can publish your own MCP server for the custom systems that matter to your specific company. The integration surface that used to be the hardest part of any build is now a protocol with a well-tested standard library.
Continue with skill composition. Two years ago, getting an AI model to reliably perform a specialized task required elaborate prompt engineering and fragile context management. Today, Anthropic's skills framework — and the broader pattern it exemplifies — provides dynamic capability loading that the model itself can invoke when the task requires it. Skills are stored as structured documents; the model accesses them by name; the context loads only the skill needed for the current task. This collapses one of the largest sources of variability and complexity in agent design.
Continue with the models themselves. The frontier has moved meaningfully in the last two years. GPT-5.4 released in March 2026 extends the agentic and reasoning capabilities of its predecessors across all domains. Claude Sonnet 4.6 is the production default for most reasoning work across the Vercel ecosystem. Claude Opus 4.6 and GPT-5.4 Pro are the premium tiers. Gemini 3 Flash and its image-preview variants cover multimodal requirements. A much wider distribution of "good enough" cheap-fast models — Haiku 4.5, Gemini 3 Flash — cover routing, classification, and tool-calling at a fraction of the cost per token of the frontier models. Cost-aware routing across this model distribution is now a design choice rather than an engineering project.
This is the substrate the surfer rides. Each of these primitives represents work that used to be custom and is now commodity. Each frees up engineering capacity for the higher-altitude work — the phase-space analysis, the friction-topology mapping, the specific operating-system design for a specific company. The same is true at an accelerating rate in adjacent primitives we haven't named: durable queues, rolling deployments, cache components, sandbox-based code execution, agent-readable content infrastructure, structured-data schemas, generative engine optimization. All of these have matured to the point where someone whose actual work is the higher-altitude design can count on the substrate holding, compose primitives that already exist as well-tested commodities, and treat the infrastructure as available capability.
This is why the Possibility Space Engineer position is specifically a 2026 position. The primitives have consolidated enough that the engineering work has moved up the stack — from making the substrate work to navigating the substrate toward valuable ends. A year ago, much of this substrate existed but required stitching together from pre-1.0 pieces. Three years ago, most of it was research. Five years ago, the idea of durable agents as a language-level primitive was science fiction. The substrate is now real. The surfboards are made. The wave is breaking. The question is who is going to ride it well, for whom.
The second implication of this substrate maturation is that the value of the person doing the higher-altitude work grows as the substrate continues to mature. This is the durable position the essay has been building toward. Every new primitive that ships is new capability the navigator can compose into the deployed systems. Every integration that becomes standard is time the navigator gets back for the work that requires judgment. Every model capability that improves is a higher ceiling for what the composed systems can do. The navigator compounds because the substrate compounds. The surfer rises because the wave rises.
One question remains: whether the same trajectory that makes the substrate increasingly capable eventually makes the navigator unnecessary. The structural case for the navigator's durability rests on what the judgment requires. The kind of judgment the navigator exercises — what trajectory through phase space a specific company should be on; what friction topology is load-bearing and what is incidental; what operating system this specific business actually needs — requires continuous, adversarial, accountable engagement with specific human stakeholders whose preferences, values, and trust dynamics are themselves moving targets. An AI can model a company; the navigator sits in the room with the founder and negotiates what the company wants to become. The partnership element — the human in human-AI partnership — is what makes the judgment accountable, legible, and revisable. As long as humans remain the stakeholders, someone whose role is to stand with them and navigate alongside them remains structurally valuable.
We are describing the foreseeable horizon. That horizon is long. For its duration, the Possibility Space Engineer is a durable role, the substrate that makes their work more powerful is compounding, and the companies that take this kind of partnership seriously will have operational capability that lives beyond what transactional engagements can produce.
VIII. The Invitation
This essay has been describing a position on a wave. If the position resonates, we would like to hear about it.
If you are a founder or operator whose work has friction you can describe specifically — the task that takes too long, the decision that's too hard to make with the data you have, the meeting that happens every week, waiting for the system that would dissolve it — we would like to talk about it. The first conversation is free. We listen; we offer our read of what we see; we name what shape of partnership we think fits, or we tell you that the fit lives somewhere else and why. We are a small practice firm, which means we work with a small number of clients at a time, and we work best when the alignment is clear on both sides.
If you lead an organization with a vision for what your company could become with AI living as the operating system the company runs on, and you have been looking for the right practitioner to partner with on making that vision real, we would like to talk. The work we do is the work of making that vision real, over the long horizon it takes for visions of this shape to fully compound into the business.
If the organization you lead is one whose mission resonates with values we hold — organizations working to feed people, organizations cleaning up our oceans and waterways, organizations restoring the environment, organizations expanding educational access, organizations serving communities where commercial support is thin — we hold capacity specifically for work like this, at commercial structures shaped to the alignment of the cause. Reach out and tell us what you are trying to do. If the alignment is real, we will find a way to do work together.
Possibility Space Engineering is the craft. The systems we build are the artifacts. The partnership is how both compound. The wave is real, the substrate is maturing, and there is a position on it that gets stronger as the wave gets larger.
We would like to meet the people who are ready to ride it well.
— David Jones, MainThread Studio. Orlando, April 2026.