Give AI What Only You Can Give It

One of my favorite prompts is also one of the simplest:

I am trying to achieve X. I am Y. Have a conversation with me to help me understand how you can help me achieve that goal.

I find this unbelievably powerful.

It does not tell the AI to adopt six roles. It does not prescribe a complicated reasoning framework. It does not try to predict every step the AI should take.

It starts with the goal, explains who I am, and asks the AI to collaborate with me.

That is what prompt engineering has become as the models have matured.

It is less about finding the right magic words. It is more about clear communication.

The next question is whether the AI knows enough about your situation to make that communication useful.

That is why I no longer think prompt engineering and context engineering make sense as separate subjects. Prompting is how we communicate with AI. Context engineering gives it the parts of our world that it cannot know without us.

You need both to get through the doorway.

How I started using prompts

My background is in software engineering and product management, so I started using AI across the product-development lifecycle.

I used it to write product specifications much more quickly. I gave it dense information to process. I asked it to compare user feedback with open tickets and help me find patterns. Seeing those patterns manually would have taken much longer.

Engineering was a large part of it too.

At the time, the main interface was a chat screen or a plug-in inside an integrated development environment. You could ask AI to generate a code chunk, a module, or sometimes most of an application.

That was impressive. It still is.

We can describe working software and receive code in return. That should not become ordinary merely because we have seen it a thousand times.

The early workflow looked like this:

Describe the code in chat
    -> AI generates it
    -> Copy it into the development environment
    -> Run it
    -> Return to chat with the problem
    -> Ask for a change
    -> Copy the revision back

The code generation was fast.

The workflow around it was not.

Prompt engineering is communication

The biggest misconception about prompt engineering is that it means knowing which words to say.

That may have felt true very early on. The models needed much more structure. You had to be disciplined about the prompt and context structures. You also had to specify the sources, expected output, and validation approach.

The models have matured since then.

I think of them like teammates becoming more senior.

A junior teammate often needs detailed direction. They may not know what to ask, which assumptions to challenge, or how to collaborate when the task is ambiguous.

A very senior teammate is different. You do not need to micromanage every step of the solution. You need to be clear about the goal, the constraints, and the reality they are operating within.

Advanced models can now work with you on decomposition, assumptions, quality criteria, and method. They can ask useful questions when information is missing.

But they cannot decide what you actually want.

The goal still has to come from you.

The constraints still have to come from you.

That is the durable skill inside prompt engineering: communicating clearly with an intelligent collaborator.

What a clear prompt contains

A clear prompt does not need to be long.

At minimum, it should help the AI understand:

• what you are trying to achieve;
• who you are or what role you occupy in the situation;
• which constraints cannot be violated;
• what decision, artifact, or next step would be useful.

You can then let the conversation do some of the work.

This is why my favorite prompt asks AI to have a conversation with me. I may not know the best way it can help. The model often knows more about its own capabilities than I do. It can propose approaches, ask for what it needs, and help shape the work.

The interaction becomes less like operating a machine and more like working with a capable teammate.

But even the most capable teammate cannot work from information they do not have.

That is where context engineering begins.

Give AI what only you can give it

As models become more capable, the most valuable information in a prompt changes.

You do not need to spend most of your time explaining general best practices the AI can already retrieve or reason through. You do not need to tell a senior model every step it should take when it can design a better approach with you.

You need to give it what is specific to your situation.

That includes:

• information unique to your company, product, or customer;
• private files and records it cannot search;
• the current state of the work;
• prior decisions and why they were made;
• goals that matter to you;
• constraints that cannot be inferred;
• information that has changed since the model's general knowledge was formed;
• access to the systems where the relevant evidence lives.

This is the simplest distinction I have found:

Prompt engineering
    = Communicate the goal and constraints clearly

Context engineering
    = Give AI the specific world around the goal

The prompt starts the collaboration.

The context makes the collaboration yours.

A strategy conversation that can start at strategy

One of the clearest examples for me is working with leadership on my company's strategic approach.

It is hard to have a useful strategy conversation with AI if every conversation begins without the company. The AI needs the vision, current strategy, and key operating facts. Sometimes it also needs the technical architecture.

Without that foundation, I have to spend the beginning of every conversation recreating the company before we can discuss where it should go.

The better version is a project workspace with a folder containing the relevant company documents. The project also has instructions explaining what the workspace is for and what kind of conversation we are having.

Now I can start a new conversation and move directly into the strategic question. The AI already has the company context, goals, and nature of the work.

Company vision + strategy + operating facts + architecture
                         -> Persistent project context
                         -> New strategic conversation
                         -> Start with the decision, not the recap

This is what persistent context changes. It lets the next conversation begin where the last one left off instead of charging the same context rent again.

Why better prompts eventually stop helping

You know you have outgrown prompt engineering when the goal requires a lot of back and forth. The AI also has to remember detailed information across the work.

If you keep rewriting the prompt but still have to explain the same things over and over, the prompt is not the bottleneck.

I felt this very clearly in the earlier coding workflow.

I could ask AI to produce code. Then I had to move the code into the development environment. When I needed a change, I returned to the chat and explained what happened. Then I asked for the revision and copied it back.

I also had to keep reminding the AI what I was trying to build, why I was building it, and what mattered.

At the time, attaching context was work in itself. The interfaces did not make it easy to provide different kinds of context. Images, PDFs, text, source files, tickets, and prior decisions all had to make their way into the conversation. You pasted what you could and summarized the rest.

Every missing piece created a chance for the AI to solve the wrong version of the problem.

The frustration was not that the model could not write code.

The frustration was that the collaboration could not hold the product together.

The models have become more capable here too. Early on, I had to give AI detailed instructions for building a specific module. Later, it became good at reading the existing code and following the patterns on its own.

Then the work moved up a level. I still had to guide the overall structure and architecture.

Now, even when that information is missing, a capable model will often look for it and confirm the direction before proceeding. A more senior collaborator knows that an architectural assumption can send the work down two very different paths. It should ask rather than invent.

Product artifacts are intertwined

The same problem appeared outside the code.

Suppose AI helps create a product requirements document. That document is not an isolated outcome.

You will probably use it to create or influence a design document. The product and design documents will guide the architecture. All of them will shape the code, tests, release, and customer communication.

The artifacts are intertwined.

In a chat-first workflow, they are often separated by manual work:

User feedback + open tickets
    -> Prompt AI to find patterns
    -> Draft product requirement
    -> Move requirement into the product system
    -> Bring requirement into a design conversation
    -> Move design context into engineering
    -> Prompt again for implementation
    -> Rebuild context when something changes

Each AI-generated artifact may be good.

The workflow can still be poor.

Someone has to make sure the artifacts stay connected. Someone has to carry the context from one stage into the next. Someone has to notice when a customer insight changes the requirement but never reaches the implementation.

Before the environments became more integrated, that someone was almost always the human using the chat.

The human became the integration layer.

There is another failure hidden inside this relay. In software development, the requirements and the reason for the application have to remain accessible to the AI. They may live in the repository or in another connected source, but they cannot disappear after the first planning conversation.

Without that North Star, small implementation decisions begin to drift. The AI may build too much or too little. It may also solve a technically reasonable problem that misses the target.

Context does more than help AI recall facts. It keeps local decisions connected to the reason the work exists.

A better artifact is not yet a better workflow

This distinction matters because AI can make one artifact dramatically faster without changing the full feedback cycle.

A product requirement that once took hours may take minutes. But the human may still have to transfer it, reconcile it with current work, and explain it to design and engineering. If that repeats after every change, the larger system has not improved by the same amount.

This is how organizations can have impressive individual AI use while seeing much smaller organizational gains.

Everyone produces faster artifacts.

The artifacts still have to find one another.

Context engineering is the first move away from that problem. Instead of treating each prompt as a fresh transaction, we make the relevant product world available across the work.

The goal is not to paste everything into one enormous prompt.

The goal is to make the right context accessible, current, and structurally meaningful.

More context is not automatically better context

Context engineering is sometimes described as giving AI more information.

That is incomplete.

An AI has a limited context window. Even as those windows become larger, unnecessary or conflicting information makes the work harder. The same is true when a teammate receives far more material than their role requires. They have to find the signal on their own.

Context becomes useful when it is valuable to the task the AI is performing.

More context becomes harmful when it is unnecessary or conflicting.

A large initiative may genuinely require a massive amount of context. That does not mean every agent needs all of it. A useful way to manage the problem is to divide responsibility by role and ask what each agent needs to know.

Shared goal and constraints
    -> Strategy agent: company direction + operating facts
    -> Product agent: customer evidence + requirements + roadmap
    -> Engineering agent: architecture + repository + tests
    -> Release agent: approved change + deployment + communication

The shared goal keeps the agents aligned. The context boundary keeps each one focused.

Conflicting context needs an escalation path

Old decisions can conflict with current ones. A meeting transcript can contain speculation that should not override an approved requirement. Ten documents can all appear authoritative while disagreeing with one another.

Modern models have become much better at noticing these conflicts. In a conversation, the AI can raise the issue and ask which source should win.

That is perfectly workable while a human is present.

It becomes a different problem inside an embedded workflow where immediate escalation may not be possible. The system needs an explicit rule for what happens when context conflicts. It may stop, route the issue to a human, or follow a defined source hierarchy. What it should not do is quietly choose the most convenient interpretation.

Useful context therefore needs structure. The AI should be able to tell:

• which source is authoritative;
• which information is current;
• which statements are decisions and which are ideas;
• which constraints are hard boundaries;
• which goals define success;
• what changed and what remains unresolved;
• when uncertainty requires human escalation.

In other words, context engineering is not attaching a pile of files.

It is making your situation legible to the AI.

Context engineering is not the same as memory

I think of context engineering as logistics. It is how we get AI the information it needs for the work.

We can attach context directly. We can give the AI access to a system and explain how to use it. We can give it guidance for searching files, records, and memories.

Memory is deeper. Memory develops as the AI performs enough actions and has enough experience to identify what should persist. It can look back at what happened and commit durable information for later work.

A source of truth answers another question: which information should the AI treat as authoritative? In search systems, we often call this grounding. The AI uses a trusted source to verify that its retrieved context is accurate.

Context engineering
    = Get the relevant information into the work

Memory
    = Preserve useful information learned across work

Source of truth
    = Define what is authoritative

Grounding
    = Verify the answer against that authority

These layers reinforce one another, but they are not interchangeable. Retrieval can find a document. Memory can preserve a decision. Neither helps if the system cannot tell whether the information is current or trustworthy.

That is why durable context, source-of-truth boundaries, and current-state records matter. As I wrote in Why AI Workflows Need Operational Data, Not Just Better Prompts, prompts help an agent think. Operational data helps the workflow remember.

Start with the goal, constraints, and context gap

You do not need a new platform to make this shift.

Start with one meaningful goal you already use AI to pursue.

First, state the goal and constraints as clearly as you can:

## Goal
What am I trying to achieve?

## My role
Who am I in this situation?

## Constraints
What cannot be violated?
What tradeoffs am I unwilling to make?

Then use the conversational prompt:

I am trying to achieve [goal].
I am [role].
These are my constraints: [constraints].

Have a conversation with me to help me understand
how you can help me achieve that goal.

As the AI asks questions, pay attention to the information only you can provide.

Build a small context map:

## Private or unique context
- Customer or user evidence:
- Product and business decisions:
- Current implementation state:
- Relevant files and systems:
- Prior attempts and outcomes:

## Source-of-truth boundaries
- Authoritative source:
- Supporting evidence:
- Superseded information:
- Open decisions:

## Artifact chain
- What will this output influence next?
- Which later artifact or system needs this context?

Do not judge the exercise by whether the next answer sounds better.

Judge it by whether you had to reconstruct less of the same world the next time.

That is the beginning of persistent context.

Better context does not move accountability

As AI gets better at interpreting context, an important question appears: what remains human?

The final takeaway remains human, especially when interpretation becomes action. We own the goal. We own the acceptable tradeoffs. We remain accountable for what the AI does with the context we provide.

If AI misinterprets the context and takes the wrong action, that is still a human and system failure. We may need to correct the context or improve the escalation rule. We may need to narrow the action boundary or reverse the action. We do not get to outsource the consequence because the interpretation came from a model.

This becomes more important as context handling becomes automated. Better context can support better judgment. It does not transfer responsibility.

The one thing no model can retrieve on its own is what comes from me. That includes what is unique to my situation and the goals I own. It also includes which outcome I am willing to be accountable for.

Prompting remains the gateway

I do not think we move past prompting in the sense that we stop communicating with AI.

You still have to talk with it. You still need to articulate the goal. You still need to clarify the constraints. There will always be ways to improve the interaction.

Prompt engineering is the doorway because it is the act of communicating with the AI.

Context engineering is the next step because communication without shared context eventually becomes repetitive and shallow.

As the models become more senior, we should spend less time telling them how to do things they can work out for themselves. We should spend more time giving them access to the reality they cannot know without us.

That is the part no general model can manufacture.

It is also where our judgment becomes more valuable.

The destination

The destination is not the perfect prompt.

The destination is to have AI become the most knowledgeable, capable, embedded partner in whatever you want to achieve.

For that to happen, the AI needs more than a clever instruction. It needs your goals, your constraints, your context, and access to the places where the work is real.

Prompting opens the conversation.

Context turns the conversation into collaboration.

In The Collapse of the Middle, I described the full journey from chat to company brains. Context, harnesses, loops, and personal agents form the path between them.

The next article will continue with harness engineering. That means placing intelligence inside the workflow instead of making a human carry every answer back into the work.

If you want guidance on getting started, email me at rick@datasaa.com. I would also be glad to compare notes on engineering agents, the SDLC, and the end-to-end product lifecycle.