Thinking

The thing I keep coming back to with AI product work is that prompts are probably the easiest part.

That was not obvious to me at first. A good prompt can feel like the whole system. You give an agent a clear job, add some context, and get something useful back. Maybe it writes the spec. Maybe it builds the feature. Maybe it catches the thing everyone else missed.

That feels pretty great.

Then you try to do it again.

Now there are three features moving at once. One agent is working from an old decision. Another finished something that no one actually approved. The useful context is split between a chat, a spec, and whatever somebody remembers from the last conversation.

It gets messy fast.

I think this is where a product operating system starts to matter. The prompt tells an agent what to do right now. The operating system tells the work where to go.

Where does an idea enter? What has to be true before development starts? Which document is current? When does a human need to make the call? What does done mean?

Those questions sound basic. They are also where a lot of AI-assisted work goes sideways.

For the systems I have been building, I keep landing on a few pieces:

1. A defined path from idea to shipped work.
2. A small set of documents that everyone agrees are current.
3. Clear points where an agent can keep moving and where a person has to approve the direction.
4. A record of decisions so the next session does not have to figure them out again.

None of that is especially flashy. Honestly, it can look like a pile of Markdown files and some rules about where things belong.

But that context matters.

Without it, the human becomes the operating system. We carry the state, remember the decisions, notice when two outputs conflict, and explain the same architecture again tomorrow. That works for a while. It probably does not work when the number of agents, products, or decisions starts growing.

The system should carry more of that weight.

I also think it has to stay portable. Models are changing too quickly to build the process around one of them. The same is true for IDEs and agent tools. Plain-text artifacts are boring, but they survive. A spec can move. A decision log can be searched. A workflow written in normal language can be adapted when the next tool shows up.

So I am less interested in building a giant prompt library than I used to be. Prompts still matter. I just do not think they solve the harder problem.

The harder problem is getting useful work to continue across people, agents, tools, and time without everyone becoming confused about what is happening.

That needs a system.

I keep seeing context treated like everything the agent has ever been told.

The full chat. A giant system prompt. Half the repository. Notes from three meetings. Maybe a Slack thread pasted in at the end just in case.

I get why. More context feels safer. If the agent has everything, it should have what it needs.

But I am not sure that is what actually happens.

The agent gets the important decision. It also gets the idea we abandoned 20 messages ago. It gets the current requirement beside an older version of the same requirement. Then we ask it to figure out which parts matter.

Sometimes it does.

Sometimes it gets weird.

What I think we need is a more specific definition of context. Context is the information required to do this piece of work correctly. It has a job. It should probably have boundaries too.

For one feature, that might mean:

1. The product vision so the work points in the right direction.
2. The constraints that cannot be ignored.
3. The current spec and acceptance criteria.
4. The decisions already made.
5. The small part of the codebase the feature actually touches.

That is very different from giving an agent the full history of how we got there.

The history is still useful. It helps us explore, argue, change our minds, and find the actual problem. I use conversation for that all the time. The mistake is leaving the result trapped in the conversation.

Once we make a decision, it should move somewhere durable. Once the spec changes, the current spec should say so. Once we learn that a technical approach will not work, the constraint should be written where the next agent can find it.

Otherwise every new session starts with archaeology.

There is a cost problem here too. Sending more context means paying to process more context. If three files answer the question, passing 300 files is not thorough. It is just expensive. The same goes for replaying a long chat when a short decision log would do.

I do not know exactly where the right limit is for every task. It will move as models improve and context windows get larger. But a larger window does not make messy information less messy.

The test I keep coming back to is pretty simple:

Could a new agent open the project, read the named context files, and understand what it is supposed to do without me retelling the story?

If the answer is no, the context probably still lives in my head or in a chat window.

That is fragile.

Conversation helps us figure things out. A context framework makes sure we do not have to figure out the same things again.

I spend much of my time thinking about structured AI workflows, token budgets, and how to build products from 0 to 1 with agent support.

Early on, the differentiator was quality.

Who could generate better copy. Better code. Better documentation. Better design artifacts. Model capability varied widely enough that output quality created separation.

That advantage appears to be compressing.

Models are improving rapidly. Tooling layers are standardizing. Structured workflows are becoming more common. The baseline level of acceptable output is rising across teams and organizations.

As capability equalizes, constraints become more visible.

Cost becomes harder to ignore.

Token cost. Compute cost. Energy cost. Latency cost. Human review cost.

The organizations that create durable advantage will likely not be the ones who simply use AI most aggressively. They will be the ones who use it intentionally.

Do you really need the largest model for this task, or will a smaller one suffice. Are you passing far more context than required. Are you regenerating artifacts that could be cached. Are you designing workflows that accumulate clarity, or repeatedly pay to rediscover it.

There is a broader implication here. Compute is energy. Energy has impact. Efficiency is not only financial, it has environmental and ethical dimensions.

The competitive frontier appears to be shifting from who can generate impressive output once, to who can consistently extract the most value per unit of compute.

In an increasingly agent-driven economy, leverage may be measured less by raw output and more by cost-adjusted impact.

That shift is subtle, but it may become decisive.

For decades we designed interfaces to guide behavior.

Color to drive conversion. Placement to trigger clicks. Friction to increase dwell time. Entire disciplines emerged around shaping attention and influencing user flows.

That model assumes the human is directly navigating the interface.

As conversational interfaces mature, more interactions will originate in natural language. A user will say, “Find me the best option,” or “Book this,” or “Summarize their pricing model.” An agent will interpret, navigate, extract, and act.

They may not scroll through your landing page. They may not experience your micro-interactions. They may not respond to your CTA hierarchy.

Instead, they say what they want. An intermediary translates that intent into structured actions.

This does not mean frontends disappear in three years. But it does suggest that the center of gravity may shift.

When interaction becomes conversational and mediated, some of the behavioral mechanics optimized for clicks lose leverage. The surface area shifts from persuasion to clarity.

Clear APIs. Explicit actions. Structured affordances that an agent can safely execute. Transparent pricing models. Well-defined capabilities. These become increasingly important.

The emerging question is not only how do we design pages that convert humans, but how do we design systems that agents can understand, reason about, and act within safely.

The teams that adapt well will likely not be those who simply build the flashiest UI. They will be those who make their systems understandable, composable, and interoperable with agent workflows.

We are not losing interface design... we are expanding the definition of interface.

Your primary audience is increasingly not a human with a mouse. It's an agent with a parser.

For years we optimized for visual impact. Animations. Client-side rendering. Content loaded after multiple API calls. Text hidden behind interactions. Pages that look beautiful but are effectively opaque unless you execute JavaScript and simulate a user session.

That philosophy made sense in a human-first browsing era.

It makes less sense in an agent-mediated one.

If your site cannot be easily scraped, parsed, indexed, or grepped from raw HTML, you are introducing friction for the systems that are starting to mediate discovery. These systems are not patient. They are cost-sensitive, token-aware, and optimized for structured retrieval.

Every extra layer of obfuscation costs tokens. Every hidden block of content requires additional compute. Every dynamic render that could have been static increases processing overhead.

There is also an environmental dimension. LLM-driven systems consume energy. If your content requires significantly more processing to extract the same meaning, you are effectively increasing the ecosystem's compute burden for aesthetic reasons.

There is a strategic risk as well. If an agent cannot efficiently understand your content, it may deprioritize referencing it. In an agent-mediated discovery layer, visibility depends on machine comprehension as much as human appeal.

Static-first. Clean semantic HTML. Structured metadata. Predictable URLs. Exposed documentation. Markdown as a distribution layer. These are not retro ideas. They are forward-compatible infrastructure.

I do not think human-readable design disappears. But I increasingly believe machine-readable structure becomes table stakes.

If your site cannot be read by a terminal window, you may find it is not read at all.