Robert Weeden

Take a Step Back

October 14, 2026 by Rob Weeden

When a coding agent gets buried in an implementation, we tell it to take a step back and reconsider the requirement. Apply that same reset to the application itself. Agents have changed how we produce software, while much of our thinking about what software should exist still follows the architecture we're accustomed to building. The same product could be constructed differently today, and that possibility deserves attention beyond the next feature.

I've spent the last couple of years working on agent context and restrictions, including the ideas in Intelligence Contracts and The Programmable Engineer. That work explored themes now familiar in Markdown instructions and software factories. This essay extends that reflection to the system itself: the choices we've inherited, the behavior we need, and the construction those choices require us to maintain.

The Choices We Inherited

An application's early choices usually serve recognizable needs. The team knows a language, a framework offers a convenient starting point, and an interface accommodates several consumers. As the application develops, those choices accumulate conventions and supporting code. Eventually, new work begins inside that structure, and improving the structure means finding a better implementation of something we've already decided to build.

A choice becomes harder to reconsider once it supplies the vocabulary for the problem. A feature needs another controller because features have controllers. A page needs a query wrapper because pages use query wrappers. Each addition fits the existing pattern, while the pattern itself becomes an assumed requirement. Its familiarity makes it easier to reproduce, including through an agent, without establishing whether it remains the most useful construction.

Flexibility and reuse can reinforce this. General interfaces and interchangeable layers preserve possibilities that future work might need. Meanwhile, ordinary implementation must discover which possibility applies, which pattern owns the decision, and which representations must stay consistent. We spend considerable effort restricting an agent's choices while maintaining architectures that offer it more of them.

The original decisions may still be appropriate. Your experience with the system helps explain their purpose and the obligations they protect. But the conditions under which you produce software have changed, and making those decisions easier for an agent to follow doesn't evaluate them again. To do that, you need a description of the product that can stand independently of its current construction.

The Behavior We’re Trying to Deliver

An ordinary booking restriction provides a useful example. At Vally, we support participant types such as adults, children, and ride-alongs. A trip could allow twenty people overall but no more than fifteen adults. The customer should be prevented from selecting an invalid combination, and the server should reject a request that bypasses the interface. A booking with eighteen adults and two ride-alongs fits the total capacity while violating the adult limit. That describes the required behavior before naming a component, controller, or data shape.

I expected a change of roughly 150 lines. The agent returned a PR of roughly 1,200, adding an unnecessary component and API layers while missing existing shared rules. Four or five corrections later, the result was around 150 insertions. Restarting with better instructions probably would have been preferable. The diff size prompted investigation; the unnecessary implementation was what made the change wrong. This familiar correction loop illustrates the construction surrounding a small requirement.

The interaction itself also deserves examination. Imagine a booking page receiving participant types, business configuration, and activity settings through separate queries for reuse and caching. The client combines those results to determine its permitted selections. We have delivered reusable data while leaving the intended behavior to be assembled downstream. A response organized around that interaction could instead supply the relevant restrictions, with the server still enforcing the actual booking.

This is where different kinds of reuse matter. Reusing an authoritative cap rule avoids another implementation of a decision. Providing general data can leave several consumers to interpret that decision separately. Both may have a purpose, but evaluating them requires following the behavior through the complete interaction rather than counting reusable pieces.

In our API, services hold the business logic. Repositories, controllers, module interfaces, gateways, and models surround them with connections and shape conventions, while the client adds its fetching code. Once the required behavior and its authoritative decisions are clear, that surrounding construction becomes something we can examine on its own terms.

The Construction We Can Generate

Repeated shapes and settled conventions provide an opportunity to derive implementation from explicit sources. If a connection follows a definition, an ordinary feature shouldn't need an agent to rediscover how that connection is constructed. It can change the source when necessary and reproduce the consequences. This reduces the number of independent interpretations involved in expressing a decision.

We already do this for part of our application. Our controllers and schemas produce an OpenAPI description, and Hey API generates a TypeScript SDK with TanStack Query helpers. Client request definitions follow the server's description instead of being maintained separately. That is a concrete reduction in repeated authorship, and a starting point for examining the rest of the API and its client connections. Hey API, TanStack Query generation.

My experiments with generation have included a semantics language that became over-engineered. Describing the existing system created another description and its exceptions to maintain. The ambition now is to derive most of our API and its corresponding client connections, perhaps ninety percent, from definitions. Application-specific query directories, repeated contracts, and backend abstractions become candidates for removal or generation, with service decisions and the customer's interaction defining what the remaining construction must accomplish.

Protobuf offers message and service definitions. Connect RPC is a separate family of libraries using those definitions for HTTP APIs and typed clients, including browser clients. Connect-Query integrates operations with TanStack Query, and a generation plugin makes individual operations directly importable in components. Those tools offer an existing foundation for connecting defined services to a web interface. Protobuf overview, Connect introduction, Connect-Query generation.

That broader ambition remains an experiment. The participant rule needs an implementation, its configured limit remains runtime data, and behavior involving permissions, failures, or meaningful transformations needs an explicit owner. Existing tooling supplies part of the construction; further generation would be needed elsewhere. The generator and its definitions are maintained responsibilities too. Their value depends on reducing independently authored interpretations rather than preserving every old abstraction in another syntax.

With that boundary established, the agent can change definitions and behavioral code, regenerate the connections, and inspect output when debugging. Enforcing that generated files follow their sources limits where independent variations can appear. The opportunity is to make ordinary feature work concentrate on the deliberate change, with more of its surrounding implementation following mechanically.

The System We Would Choose Today

Take one ordinary interaction in your application and describe it without using the names of its files, frameworks, or architectural layers. Establish what the customer does, which business decisions govern the outcome, and what evidence would demonstrate it. That description gives you a starting point for considering how you would build the interaction today.

Extend that consideration across the system. Evaluate a language by the work of expressing those decisions and constraining their construction, including the work performed by agents. Evaluate a framework by the recurring implementation it removes and the conventions it introduces. Consider whether the interaction pattern expresses the product's intended actions directly, and whether the hosting arrangement supports its actual operational needs. Compare those choices together, because a convenience in one part can create coordination elsewhere.

A simpler system makes required behavior easier to explain, change, and verify through fewer independently maintained interpretations. A smaller file count alone doesn't establish that, and a generated version of the same architecture may leave the work largely intact. The final handwritten participant-cap change was already small; a better construction would make that appropriate result easier to reach repeatedly with less reconstruction and correction.

My favorite key is the backspace key because the best software is the smallest software.

The outcome of this reassessment might be a different stack, a more specific interface, a generation experiment, or renewed confidence in choices that still serve the product. It gives you a basis for deciding where change would help. Your existing knowledge remains valuable because it identifies obligations a fresh design might overlook; it also allows you to separate those obligations from the particular machinery that currently fulfills them.

Compare the system you would deliberately choose today with the one you keep modifying. Each difference points to a choice worth examining, whether it concerns a language, an interaction, or a repeated layer of connective code. Give those choices the same scrutiny you give an agent's proposed implementation. Your product's behavior can remain the commitment while its construction becomes open to consideration again.

The Programmable Engineer: Another Way of Thinking About the Production and Management of Tech Debt

December 31, 2025 by Rob Weeden

Abstract

The purpose of this essay is not to convince anyone that the current paradigm of software engineering requires fundamental change, but rather to encourage engineers to reconsider their entire toolchain and examine how previous programming decisions impact code production practices. This essay provides a potential framework for thinking about tech stack decisions in the age of autonomous code-producing machines. As large language models demonstrate increasing proficiency in code generation, we should reassess what it means to engineer software, where technical debt originates, and how we can architect systems that treat natural language as a first-class programming interface.

The Evolution of Development Velocity

Software development has undergone several paradigm shifts in how we manage the trade-off between velocity and quality. The Waterfall methodology, introduced in 1970, treated development as a sequential process where problems found late could cost orders of magnitude more to fix than early detection.^[1] Then came Agile: in February 2001, developers met at Snowbird, Utah and created the Manifesto for Agile Software Development, emphasizing individuals over processes, working software over documentation, and responding to change over following plans.^[2] This shift allowed businesses to iterate faster, receive feedback continuously, and adapt to market demands with minimal friction.

Yet one constant persists: technical debt. The persistent reality that choices made today impact our capacity for technical decisions tomorrow. There exists a general consensus that proper software development involves trade-offs between accumulating tech debt and the velocity at which businesses design and implement customer solutions. I believe this trade-off will forever characterize software engineering. But 2025 has been proclaimed by many as the year of the agents—autonomous programming systems that aid developers in code production. Substantial debate surrounds code quality and improvement strategies. What I have yet to encounter is reflection on how these agents might fundamentally alter the economics of that trade-off, potentially introducing a new paradigm comparable to the shift from Waterfall to Agile.

Consider this: if documentation becomes execution, if natural language instructions reliably produce working code, then velocity transforms entirely. The question becomes not "how fast can we write code?" but "how fast can we document what we want, and is our tech stack configured to accept natural language as instruction?" This is Agile on steroids—a potential methodology where the primary constraint is the clarity of your requirements and the determinism of your validation systems. Your tech debt becomes the friction in this translation process.

Natural Language as a Programming Paradigm

A large language model functions as a statistical black box that accepts human language in any form as input—including human language as a superset of programming languages. These models understand both natural language and every programming language devised by man. While this is not a revolutionary insight, what appears forgotten is how human language can be properly leveraged as a programming interface.

Software engineering, as I understand it, is the practice of translating a constrained set of business ideas into programmatically executable software that meets customer requirements. As any experienced developer will attest, how you accomplish this depends on selecting the right tool for the job. The question is whether we are still using the right tools given this new natural language programming paradigm.

I reflect on the famous "Atwood's Law" proposed by Jeff Atwood a co-founder of Stack Overflow: "Any application that can be written in JavaScript, will eventually be written in JavaScript". I interpret this as recognition that JavaScript represented, at the time, the most comprehensible programmatically executable language invented—it was easy to read because most software was written in nearly plain English. It was easy to build a company around, and thus we saw the javascript ecosystem flourish. But as history demonstrated, JavaScript alone was insufficient. The loosely typed system demanded deterministic additions, leading to TypeScript's invention to leverage flexibility while attempting to mitigate pitfalls.

This shift toward natural language does not, as some might hope, eliminate the "essential complexity" that Frederick Brooks described in No Silver Bullet—the inherent difficulty of designing complex logical systems. Rather, it represents the ultimate tool for automating the reduction of "accidental complexity". If the history of software engineering is a long war against the friction of syntax, memory management, and build tools, then the programmable engineer is our most powerful weapon yet. By delegating the "accidental" labor of code production to an agent, the human engineer is finally unburdened from the minutiae of implementation. However, this creates a new urgency: when the cost of clearing accidental complexity approaches zero, the "essential" debt of our architectural decisions becomes the only remaining bottleneck. Our tech debt is no longer just "messy code"; it is a navigational hazard that prevents the agent from accurately mapping our intent to the machine's execution.

The Black Box and the Robot: Understanding Agent Architecture

A typical developer workflow now involves typing or speaking to a programming agent, expecting it to do what we say and write code as we would. This agent is not merely a large language model—the model serves as the black box, while the agent is a mechanism containing that black box that loops through it given an objective. Think of it as a cartoon robot with a black box in the center of its belly. The robot has arms. An agent uses its arms to grab pieces of context and feed them into the black box, producing code that meets the criteria of the input.

A Brief Technical Primer

To understand how agents actually work, we need to clarify what that "black box" really is and what gets fed into it. The context window is the input into the black box—it's everything that gets packaged up and sent to the large language model for processing. Large language models are fundamentally stateless—they possess no memory between interactions.^[4] Each time you send a message to an agent, the entire conversation history, all accumulated code snippets, tool outputs, and configuration files must be sent fresh to the language model. The model doesn't "remember" your previous messages; it's being reminded of them with every single request.

This context window is measured in tokens (roughly equivalent to words), and it has a size limit. Modern models like Claude can handle hundreds of thousands of tokens, but every token costs money and processing time. More importantly, this stateless architecture is why context management becomes critical. When you use an agent, configuration files like .cursorrules or claude.md are automatically injected into the context window with every request. When you enable MCP servers, those tool definitions are also added and consume the available tokens in the context window. When the agent reads your codebase, or calls an mcp tool, that code fills the context window. Every interaction is a fresh calculation based entirely on what fits in that window at that moment.

This is why both layers of control matter: natural language instructions guide what the agent's "arms" grab and put into the context window, while programmatic constraints validate the output after it emerges from the black box. The agent loops—grabbing context, filling the window, getting a response, executing tools, and repeating until the task is complete.

Controlling the Entropy

This is inherently a non-deterministic function. Large language models are fundamentally random statistical calculators, but that randomness is controllable by the input. If you envision that robot with its black box belly as an engineer with a PhD in pattern recognition, interesting scenarios emerge. The distinction is important: pattern recognition rather than software engineering. This framing helps clarify the relationship between three entities: the software engineer operates the agent, the agent leverages the large language model to pick tools, and the entropy mechanism resides within the model itself on api calls to the LLM provider. Understanding this hierarchy reveals where we can impose control and where inherent uncertainty remains.

I believe we can place sufficient restrictions and guardrails on the agent such that the entropy shrinks to an acceptable level. Given the right tech stack, documentation, and communication practices, we can effectively mitigate the randomness of the system. If this is possible, could we not scale this idea significantly? Could we not have multiple programmable engineers producing desirable code simultaneously? Would it not follow that the software engineer, now unburdened by the task of writing code, would have more time to contemplate the translation process, customer requests, testing mechanisms, and actual implementation of each feature?

In this framing, deterministic validation and testing harnesses do more than verify correctness; they function as entropy- and hallucination-reduction mechanisms by confronting agent output with unambiguous programmatic reality.

Two Layers of Agent Control: Connecting the Ligaments

There are two ways to constrain an agent: from within the entropy system and from outside it. Both are necessary. The combination creates what I call the ligaments—the connective tissue between flexible natural language instructions and rigid programmatic validation.

The industry has embraced natural language instructions embedded in configuration files. Six months ago, I wrote an essay called "Operator|Contract|Workflow" proposing exactly this: markdown files that instruct agents how to behave. These files are injected into the context window with every request, providing consistent guidance. But natural language alone is insufficient. The model has seen countless different ways to solve the same problem in TypeScript, countless different libraries and frameworks, countless different architectural patterns. This abundance becomes noise when you're trying to establish consistent patterns in your codebase. The solution is half-baked.

The correct combination of both layers creates the programmable engineer. Natural language instructions guide behavior within the black box. Programmatic constraints—linting, type checking, compilation, testing, shell scripts, API integrations, patterns, programming practices—provide hard boundaries outside it. When an agent receives an error from the compiler, test suite, or validation script, that feedback is deterministic. It's not asking the model to remember instructions; it's confronting it with programmatic reality. In addition, clever ideas like hooking into the file creation process and enforcing a file naming pattern on creation. Or utilizing your project management tool for your code branching strategy and developer workflow.

This dual-layer approach also avoids context bloat. Rather than cramming thousands of lines of instructions into markdown files or relying on injected approaches like Model Context Protocol (MCP) that hide complexity, we use small, repeatable scripts and integrations that both humans and agents can execute. The Linear script is short and the validation hooks come out of the box with Cursor Agent. The linting rules are standard configurations. Each piece is comprehensible, debuggable, and deterministic. The ligaments are visible.

Reimagining Technical Debt: The New Economics of Simplification

If producing high quality code is getting cheaper—where does the cost live now? Does it live in the bugs? The logical errors, the edge cases missed, the sloppy patterns that compound over time. Whether those bugs come from human programming mistakes or from agents producing code that compiles but doesn't quite capture the intent, the result is the same: we spend significant time debugging, fixing, and maintaining.

This changes how we should value technical debt. Traditional tech debt calculations weigh the cost of complexity against the speed of delivery. Move fast, accumulate some mess, pay it down later when it becomes painful. But if code production approaches zero cost while bug fixing remains expensive, does the equation shift dramatically?

Consider tech debt that stems from overcomplicated architecture, inconsistent patterns, or sprawling dependencies. Cleaning up that kind of debt has always had value—it makes the codebase more maintainable for human engineers. But now it has double the value: it simplifies things for human engineers and for an infinite number of programmable engineers. When you consolidate three different ways of handling react state management into one clear pattern, you're not just making it easier for your team to understand. You're making it possible for the agent to identify a single, consistent rule that will be followed reliably in its area of work.

The ROI calculation on simplification work changes completely. Refactoring to reduce dependencies? That's not just technical hygiene anymore—it's infrastructure for agent-driven development. Establishing clear architectural boundaries like "only the repository layer touches the database"? That's not just good practice—it's a constraint that both humans and agents can validate programmatically. Choosing an opinionated, batteries-included framework over a flexible but complex one? That decision now impacts whether your agents can reliably navigate your codebase or constantly produce variations that require human review.

Technical debt becomes a question of navigability. Can a human engineer—or an agent—look at your codebase and quickly understand the patterns? Can they predict how to fetch data from a client component, how that data flows through layers, what conventions govern naming and structure? If the answer is no, if inconsistency and complexity create friction, then every piece of code produced—by human or agent—carries a higher maintenance burden.

The cost-benefit analysis weighed with most technical decisions needs adjustment to reflect this new reality. Writing high-quality code is becoming inexpensive. The most expensive component of software development has been paying engineers to fix bugs. But if we have programmable, scalable engineers capable of producing code at the level of the rest of the team, then the job of software engineers becomes thinking about problems and documenting software behavior, rather than getting mixed up in the minutiae of code styling, formatting, placement, and naming. Engineers should be positioned to think about business problems and how to solve them with software, not software problems and how they impede the business.

This is not a call for perfection or premature optimization. It's a recognition that the economics have shifted. Complexity that was once tolerable because "we'll fix it when it breaks" becomes intolerable when it multiplies the surface area for agent-produced bugs. Simplification that was once nice-to-have might become essential infrastructure. The programmable engineer amplifies whatever state your codebase is in—if it's simple and consistent, you get reliable output; if it's complex and inconsistent, you get unreliable output at scale.

A Different Perspective

This represents a fundamentally different way of viewing our current environment. My opinion is that the current state of software is generally unhealthy. Applications require constant updates before they function. They are slow, consume substantial resources, and require significant capital to maintain.

However, approaching code production from an English-first perspective—a naturally human approach—provides us a way of reevaluating our businesses from the ground up. While it will always remain true that an engineer's job is to read code and make sure it behaves as the customers require, I no longer believe it is the job of the engineer to write all of their code.

Some years ago, machine learning algorithms were trained to scan radiology imagery and identify potential health issues in patients. These algorithms became so proficient that modern radiology imaging can detect anomalies better than most human radiologists. At the time, this frightened many people, and there were fears the radiology profession would disappear. Several years later, there are more radiologists than ever. This is because the job of the radiologist is to detect and investigate potential diseases, not to look at imagery. Looking at imagery is a task of the radiologist, much as writing code is a task of the software engineer. I believe we are at an opportune position in technology and AI progress where we as engineers should take honest time to reevaluate what it means to write code, what it means to engineer and architect software, and potentially rebalance our mental perception of tech debt, how rapidly it accumulates, and what it truly costs us.

Conclusion: A Call to Reflection

This is not a call to action for drastic changes in your codebase. This is a call to action for reassessment of what we do on a daily basis. How much time do we spend developing patterns and abstractions around our tech debt, around our dependencies, around our ecosystem issues? If producing code is now substantially less expensive, then many new doors are available and many new levers exist to make translating business ideas into programmatically executable code more efficient.

The implications are profound. If we can construct systems where natural language serves as a reliable programming interface, constrained by recognizable patterns and validated by programmatic checks, then the nature of technical debt itself transforms. It is no longer solely about the code we write today limiting our options tomorrow—it is also about the systems we design today limiting our ability to instruct agents tomorrow. The tech debt of the future may be measured not in lines of code requiring refactoring, but in the comprehensibility and consistency of our architectural patterns, the clarity of our documentation, and the determinism of our validation systems.

This essay does not provide definitive answers. Rather, it poses a question that I feel demands serious contemplation from every software engineer: as the cost of code production approaches zero, what becomes valuable? I propose that what becomes valuable is not the ability to write code, but the ability to think clearly about problems, to architect systems that are comprehensible to both humans and machines, and to translate business needs into specifications that can be reliably executed by increasingly capable autonomous agents. The tools are changing, and we must consider whether our thinking should change to match.

Bibliography

[1] Royce, Winston W. "Managing the Development of Large Software Systems." In Proceedings of IEEE WESCON 26, 1–9. Los Angeles: IEEE, 1970. https://www.cs.huji.ac.il/~feit/sem/se09/Waterfall.pdf.

[2] Beck, Kent, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, et al. "Manifesto for Agile Software Development." Agile Alliance. 2001. http://agilemanifesto.org/.

Atwood, Jeff. "Atwood's Law." Coding Horror (blog). July 17, 2007. https://blog.codinghorror.com/the-principle-of-least-power/.

Brooks, Frederick P., Jr. "No Silver Bullet—Essence and Accidents of Software Engineering." Computer 20, no. 4 (April 1987): 10–19. https://doi.org/10.1109/MC.1987.1663532.

[4] Brown, Tom B., Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared Kaplan, Prafulla Dhariwal, Arvind Neelakantan, et al. "Language Models Are Few-Shot Learners." In Advances in Neural Information Processing Systems 33 (NeurIPS 2020), edited by H. Larochelle, M. Ranzato, R. Hadsell, M. F. Balcan, and H. Lin, 1877–1901. Curran Associates, Inc., 2020. https://proceedings.neurips.cc/paper/2020/file/1457c0d6bfcb4967418bfb8ac142f64a-Paper.pdf.

Intelligence Contracts: A New Paradigm for AI Governance

June 2, 2025 by Rob Weeden

Download PDF: are you paying attention?.pdf

Around the same time as the writing of this paper other industry movers stumbled upon a similar idea. Markdown files that guide agent behavior became an industry standard with formats like AGENTS.md, Claude.md, and .cursor/rules

Abstract

The current rapid adoption of Artificial Intelligence across the global business ecosystem has created novel, complex, and daunting challenges in the face of personal data privacy, proprietary knowledge, and human intellectual property. While it's become apparent that the leading AI firms take strict safety precautions regarding the training and behavior of their models, the rise and demand for open source alternatives and the general diffusion of AI tools and knowledge suggests that this might not be enough. In the digital age of misinformation and deception, it's becoming increasingly difficult to establish trust between individuals and organizations. This essay proposes a new trust paradigm, built for personal security, flexibility, and ease of understanding, that enables safe coordination between humans and autonomous agents through mutually understood contracts.

The Discovery: Drawing the Line

During a long but routine programming session with my autonomous agent, Cursor, I encountered an anomaly. The agent and I were constructing what I now call a "knowledge pipeline"—a general understanding of what my new business system was supposed to do. I work well in teams, so my collaboration with Cursor Agent was tight and I felt that I was actively learning a new perspective of my system. However, I maintained complete control of the agent. In other words, I felt as if I was driving a machine in unknown territory.

We were working on describing the expected behavior, background knowledge, intended use, and technical structure of a broader ecosystem of data sources: a Discord server with alerts, the Cursor editor with knowledge of the codebase, and access to a remote database, all combined to create an automated debugger that would be controlled by a human to quickly and efficiently debug alert messages. What I noticed was that, although Cursor and I had a very similar understanding of the intent and structure of the system, it would occasionally make incorrect assumptions about the ecosystem as a whole, and what we were doing there. This created a feedback loop between myself and the agent, where I would ask it to correct its understanding, it would correct and document its changes in a README.

Then I exhibited an unexpected behavior. I told Cursor to reinforce its understanding of the intention of this tool ecosystem by reviewing the semantic descriptions we had created, and write it in a way that "you (Cursor) understand best". Cursor understood my request, and opted to add a section to the bottom of the file full of markdown quick reference tables and decision trees. At this moment, I knew I needed to draw a line.

I created a "reflection line" in my markdown that illustrated to Cursor that all of its understanding must be derived from the semantic description above the line. This line delineated the stoppage of human description and the beginning of autonomously generated code. After this revelation, I instructed Cursor to implement a safety checklist at the top of the file that stated it would reflect on the semantic understanding to derive its quick reference tables. This inherently created a system where the agent must first read the rules of engagement and understand the system, before it may generate its own "trains of thought". After adding more safety rules, the file quickly turned from a README into a binding contract between myself and the agent. After brief interrogation, it appeared Cursor would "respect" this line. From there I instructed it to pause and begin summarizing what we had been talking about.

The Core Insight: Mutual Understanding as a Prerequisite

My interpretation of this experience is that human-to-agent interaction can be safely coordinated if and only if all parties come to a mutual understanding of how the data will be handled. It's not currently clear what big providers like Anthropic and OpenAI do to assist in maintaining safety throughout the ecosystem. We know they "train" their language models, but what does that mean? Are they ingesting copious amounts of personal data that is then cooked into the knowledge base? These large language models should not know where our customers live, or what my dog's name is. They should be trained to respect lines drawn in the sand by operators of said agents.

All of this is to say that I've discovered an architecture that is universally understandable by both human and modern machines. It provides a way to apply modern AI inference and intelligence in an effective and critically helpful manner. By adopting a standard of Operator|Contract|Workflow, it is my understanding that these language models can be taught to respect boundaries when given autonomous exploratory authority.

The Architecture: Operator, Contract, and Workflow

Let me be concrete. I am creating a workflow—an autonomous set of tasks that I want an agent to follow. I define a contract (.contract.md) file somewhere. This could be in a codebase, like in my example, or it could be in a Google Drive, or Claude Desktop. This file contains the rules of engagement regarding activity within the ecosystem, such as "never access the admin-key database" or "immediately forget any personal information you come across after completing the task at hand". But it also contains a broader understanding of the system, such as "we have 3 database clusters, they are db-prod, db-preview, db-development" or "you have access to everything in this Google Drive except for the family-finances directory". When the agent begins its context with the operator, it immediately reads the contract and understands the limitations of its knowledge and exploratory ability. As the agent proceeds with its tasks, it needs to constantly reflect on the contract, maintaining strict adherence to the limitations set up by the controller.

This contract, when applied in a functional manner, is represented as a workflow. The workflow is a set of tasks that are generated by human-agent discussion that guide an agent down a general train of thought. In my specific example, the general workflow was:

Retrieve alert -> extract sensitive data -> determine environment -> switch environment -> access more sensitive data -> interpret / analyze -> report back

The workflow could be as general or specific as the operator sees fit. In my case, I placed the agent in a role and described the scenario, as well as provided guidance on when this workflow should apply and the general steps. For example:

Your Role: Senior Software Engineer

You're debugging a production or preview alert from Discord using Eugene, your specialized MCP debugging assistant. Your mission is to quickly identify issues, present data, and provide actionable fixes.

Key Partnership:

• You (Cursor): Orchestrate the entire debugging workflow—analyze alerts, extract IDs, make intelligent decisions, call database MCP tools directly using embedded .contract mappings, perform codebase analysis
• Eugene (MCP Server): Handle Discord connectivity only—fetch alerts and post formatted responses (2 tools)

When This Rule Activates

Use this workflow when operator mentions:

• "debug", "debugging", "discord alert", "production issue"
• "eugene", "mcp server", "error analysis"
• "latest alert", "recent alert", "mongodb investigation"
• "verbose analysis", "detailed summary", "verbose debug"—triggers detailed 8-sentence response format
• "quick summary debug"—confirms short 3-sentence response format (default)

Or a more universally understood example might be placed in a Google Drive and say:

"You're a senior technical analyst at an insurance company. Your job is to make sure people are properly compensated for their healthcare expenses. This workflow describes the process of analyzing medical expense reports, searching for signs of fraudulent money laundering, and creating an Excel spreadsheet with statistics.

If you come across hospital expenses over what the average household can afford, you should notify the operator and stop."

The Need for Individualization

While these ad-hoc examples might seem inconsequential on a surface level, they illustrate a more general demand for individualization of these systems. The domain knowledge and safety requirements for everyone are different. Some industries have legal guidelines for handling data such as the United States' HIPAA regulations, while others have customer bases that demand privacy. This high degree of variety makes it nearly impossible for industry leaders to create systems that meet the security and privacy needs of everyone.

The Intelligence Contract represents an evolution in AI safety, industry adoption feasibility, and workflow automation. It provides a standard, universally understood contract for the Operator, the Large Language Model provider, the Autonomous agent, and the broader AI ecosystem to adhere to. This intelligence contract serves as both a literal agreement semantically defined in markdown, and a mutual understanding amongst the AI ecosystem that while this newfound technology provides incredible opportunities for growth in industry, science, and business, it also poses an unprecedented risk to privacy and property. We must recognize that the individuals who are most familiar with the boundaries should be in charge of the intention, understanding, and access of these autonomous agents.

The Dual-Faceted Contract

It's come to my attention that there is still more to explain. I struggle to emphasize the importance of this contract structure in the broader understanding of AI technology. The contract represents an agreement of safety and control between normal individuals and large firms full of smart people that build these technologies. Through collaboration between the community and companies, it is my strong belief that we can safely and quickly integrate artificial inference into the broader global economy. The markdown contract and its inherent agreements represent the diffusion of AI knowledge throughout the tech stack, all the way to the consumer. Markdown is a language that is incredibly flexible and portable, capable of supporting operational semantics, safety restrictions, data processing agreements, and most importantly, universally understood by the common man. The discovery of the Intelligence Contract acts as an agreement between consumer and provider, that this is how these systems ought to be controlled, with the consumer behind the wheel. However, this contract requires near universal adoption by the broader ecosystem, encompassing open source tools, industry leading firms, and the common man in order to control autonomous agents in this manner. The flexibility of markdown contracts offers opportunities for those privacy-focused to self-host tooling that adheres to standards, while also providing industry opportunity for firms to build adhering systems.

On the flip side, this contract serves as another evolution in programming. A mentor of mine once said that "programming is just translation of intention into machine code"—or something along those lines. The new contract structure follows a paradigm we at work have been calling "semantic programming" for years. It's a description that is intended to be understood and constantly adhered to by autonomous agents. These agents are capable of more than we give them the capability to do. With semantic encoding of knowledge and understanding in the hands of the average man—the non-technical—workflow automation will reach bounds never considered. The reflection process of this contract is paramount. That's where the trust is verified. By offering a reflection line that presents the agent's thinking patterns, the common man is able to understand and validate the thinking process of the agent and its understood boundaries and restrictions. With this auditability standardized throughout the toolset, an operator is able to debug their own agent. For example, if an operator is attempting to build a workflow and recognizes that an agent isn't following data privacy restrictions, the operator ought to cease use of that agent and validate their semantic understanding of the task via agent interrogations. If the agent appears to understand the task, but its generated code doesn't reflect the correct understanding, then the agent or backing model ought to be considered "broken". If it can't understand human logic, it shouldn't be doing human tasks.

Democratization and Consumer Control

The auditability of this paradigm presents a novel opportunity to shift the responsibility of data privacy and personal data safety onto the consumer. By setting up a system in which the model and agent providers build technology that adheres to contracts, the Operator is put in direct control of what data is processed and more importantly how it is processed. Referencing my example, the Operator might define in the contract that "no personal data should ever be used for the training of models" and "you have access to a codebase but you should never share your understanding of our code with anyone else". In this way the Operator is able to define restrictions and controls for privacy. This presents a novel opportunity for the common man, those unfamiliar with the absurd complexity of modern computing and programming. The contract is a democratic paradigm for governing data access and understanding in the modern digital age.

A Note on Theory and Implementation

I'd like to emphasize that this is all theory. I halted implementation of the Eugene debugger so that I could record my discovery. Without adherence to this contract, I'm not currently comfortable turning Eugene on and letting it access customer data. I need reassurance from someone of relevance that this data will be respected and handled as defined by me, the Operator.

Conclusion: A Call for Universal Adoption

The Intelligence Contract represents a fundamental shift in how we think about AI governance, privacy, and the relationship between operators and autonomous agents. It provides a framework that is both technically sound and accessible to non-technical users, enabling a new level of control and transparency in AI interactions.

The implications are profound. If we can establish a standard where contracts serve as binding agreements between operators, agents, and providers, we create a foundation for safe, scalable AI adoption across industries. The contract becomes both a safety mechanism and a programming paradigm—a way to translate human intention into machine behavior through semantic understanding rather than explicit code.

This essay does not provide definitive answers, but rather proposes a framework that demands serious contemplation from every individual and organization working with AI systems. As autonomous agents become increasingly capable and widespread, the question becomes: who controls the boundaries? I propose that the individuals who are most familiar with those boundaries—the operators, the domain experts, the privacy-conscious users—should be in direct control. The Intelligence Contract provides the mechanism for that control, but it requires near-universal adoption to be effective.

The tools are changing, and we must consider whether our thinking about AI governance should change to match. The Intelligence Contract offers one path forward—a path that puts control in the hands of those who understand the context, the boundaries, and the consequences of autonomous agent behavior.