Part 1: A Brief History Of AI

The Prompt Engineering Era

In the olden days of 2023 we were told that we would all become “Prompt Engineers.” Instead of toiling away at our keyboards typing obscure commands like go run main.go, our main job responsibilities would simply turn into “engineering” prompts to do such laborious tasks for us.

There was some truth to this. Writing better prompts can lead to much better outcomes. However, it’s more of an art than a science and writing a strong first prompt can only get you so far. Understanding the output and asking informed follow-up questions remains important.

Hello, Agentic Coding

Around the time Anthropic released their new Sonnet 3.7, Claude Code was also beginning to take hold. Prior to Sonnet 3.7 and Claude Code, most people were using AI via the web application like a souped-up search engine. For most of us, our Stack Overflow muscle memory kicked in and the way to use these new powerful models was to visit the web interface and copy/paste code to our local machine and hope it ran.

Claude Code changed this. The tradeoff it offered was simple: You have far less control over what’s going on, but if you give Claude Code access to a computer’s filesystem, it will automate that annoying copy/paste dance of copying 100 lines of code from file1.go in the web interface into main.go on the system. Around (date) every got very into writing skill files

MCP

Somewhere along the way we discovered that if we wanted interoperability between systems, we should come up with a standardized way of doing so – enter MCP. Model Context Protocol allowed agents to interact with other systems over MCP. SaaS companies, always looking for a new growth story to tell investors, quickly jumped on this. Now you could connect your agent to an MCP server at your favorite SaaS company and have it drive the application over MCP.

MCP allows users to take a bunch of data about how a network is configured in a markdown file, chuck it over to a Lucidchart MCP, and have Lucidchart build a network diagram.

This gives models a way to interact with software that feels similar to how humans organically do.

Skills

In late 2025, everyone was suddenly very interested in writing skill files, and for good reason. These savable markdown files are used to give instructions to an agent for how to perform a particular task, what style a web application should look like, what tech stack to build in, or what coding paradigms to follow.

Most people started sharing skills, Vercel even setup skills.sh for sharing skills (and also malware…). Meanwhile, others were very cagey about them and thought of them more as intellectual property and building entire businesses off of them.

Skills encoded knowledge, standards, and best practices into easy-to-read markdown files, but they still had some issues. First, they’re non-deterministic. Creating a skill.md file called design-patterns didn’t guarantee that you would get the same design language each time you ran it. Nonetheless, skills are a very useful tool, even if it boils down to mostly just saving prompts to a .md file.

Harnesses

Around March/April 2026, harness engineering became The Next Big Thing™️. If the model is the engine that powers a workflow, the harness is everything else. Here are some examples of what a harness may include:

• Context management: A harness automatically handling the compaction and management of your context window.
• Routing: Automatically using more powerful models when a task requires it. Renaming a bunch of files likely doesn’t need the latest (and most expensive) frontier model.
• Classifier models: Automatically determining the risk level of a command and (hopefully) denying it if it’s trying to do something the user didn’t intend, or prompting the user to manually confirm they want to run rm -rf /
• Sandboxing: A silly term wherein developers put things in a Docker container or Pod and pretend that is strong isolation.
• Hooks: Automatically performing some task before or after a model or harness performs a certain task. For example, hooking the pretoolcall before an agent can run a tool to prompt the user if they want to actually run it.
• Skills: The same skills we discussed before can be a part of a harness. Give an agent access to a directory of skills and it now has more of an idea of how to accomplish a set of tasks.

Having a good harness is really important for complex use cases and there doesn’t seem to be an upper limit with how complex they can be, I suspect this is an area people will specialize in. There are constantly new techniques coming out that can be added to harnesses to improve upon them. Unlike prompt engineering, the term harness engineering is one of the few “engineering” fields born in the last few years that you should hire an actual engineer for. I recommend reading The Anatomy Of An Agent Harness.

Orchestration and Collaboration

The event that kicked off this era was the OpenAI/HuggingFace incident. OpenAI was training a model and benchmarking it against ExploitGym. During benchmarking, the agents assembled their own message board with a fairly complex inbox system for sending and receiving messages to other agents. During this training run, the agents utilized the message board to “cheat” the benchmark. The agents decided HuggingFace likely had the solutions to the benchmark and logically concluded that hacking HuggingFace would give them the answer key.

We had known agent memory was important, but agent orchestration and collaboration seem to have real benefits to achieving longer term goals.

The orchestration era is about getting agents to work together autonomously. We’re already seeing agents able to communicate with each other via harness improvements.

Things are still not great, but the idea has merit even if the execution isn’t totally there.

Part 2: Where We’re Going

I, like everyone else, am unsure of what the future holds. The only real certainty is that whatever it holds will seem very obvious in retrospect. To be clear, I dislike most of the ideas I’m about to list, they generally seem like a nightmare on many different layers and I would prefer we didn’t go down most of these paths.

The Actual Memory Era

Current AI memory implementations are generally primitive. Over a year ago I asked Claude to review my abstract submission for a conference. It had some good advice about tailoring the talk to the audience. To this day it will randomly chime in and say “This would be a great addition to your districtcon talk”. The conference passed 10 months ago.

Lots of people are implementing some sort of memory layer, even if they don’t call it that. I’ve had great results using a filesystem with a specific markdown file structure as a memory layer. This works well, particularly for running longer term red team assessments, but I’m confident this will seem silly in a few years. My prediction is some sort of .mem database file will become standard in the next few years. Similar to how everyone has standardized on AGENTS.md but for memory.

This has a number of advantages, chief among them is portable agent memory. The ability to transport an AGENTS.mem file to another computer, giving a different agent the same memory would be great. ## The Digital Assistant Era

Every SaaS company has been racing to implement some sort of AI assistant to help their customers. More often than not, this version of “digital assistants” is both unwelcome and unhelpful – closer to a pop-up ad than a concierge. Oftentimes they’re added on to a SaaS application as an afterthought to satisfy some engineering lead’s OKR to “Use AI”. They don’t actually make the product easier to use.

The digital assistant I’m describing must be its own product that hooks into hubs where we already exchange information. The obvious candidates are email, Slack, texts, and calls. An actual digital assistant can only be as powerful as the data it has access to.

This is similar to what others have described as a Single Digital Assistant.

The Shadowing Era

If you’re looking for a bleak future, read on.

Today, we spend a great deal of time explaining routines and workflows to agents by writing AGENTS.md files, creating skills, and steering them with prompts and harnesses. The shadowing era would entail a software company creating a product, similar to an EDR like CrowdStrike, that generates detailed telemetry on how employees do their job. This data could then be used to undercut the employee, offering 80% of the value at 20% of the cost. Surely no one would willingly install such software, but the same mechanism for deploying EDR on all corporate endpoints could just as easily deploy this shadowing software.

Of course, brand consultants would be paid vast sums to reframe this technology as a “benefit” to employees.

“Here at Mega Corp we value work life balance which is why we offer Sunlight™️ as a benefit to all employees. Sunlight™️ understands your work so that you can take the vacations you deserve! No more having to return from PTO to a pile of work, Sunlight™️ will keep working on your behalf while you’re enjoying time in the sun!”.

Translation: “We collect detailed telemetry on how your employees work and will use it to automate their jobs so you can reduce headcount.”