My Prompt Diary: Why Better AI Prompts Are No Longer Enough

November 7, 2026 · Prompt Engineering / AI Agents / Developer Tools

For a long time, prompt engineering seemed to be about finding the perfect words.

Give an AI model a role. Add some context. Explain the task. Specify the output format. Maybe include a few examples.

And suddenly, the results become noticeably better.

That approach still works for many everyday tasks.

But something interesting is happening as AI systems become more capable.

The challenge is no longer simply getting a model to produce a good answer. It’s getting an AI agent to perform a sequence of tasks reliably, remember the right information, use the correct tools, and avoid doing things it shouldn’t.

Recent developments in agent frameworks and security research highlight this shift.

One example is LangChain’s Deep Agents framework, which received several updates on November 5, 2026. Among the changes were improvements to context summarization, subagent behavior, and workflow tracking.

Those might sound like relatively minor engineering details.

But they point toward a much bigger change in how we should think about prompting.

The future of prompt engineering may be less about clever instructions and more about designing reliable systems around those instructions.

The problem with the perfect prompt

Imagine asking an AI assistant to research five emerging technologies and prepare an article.

A simple prompt might say:

“Research the latest AI trends and write an interesting article.”

The result could be useful, but it leaves almost everything open to interpretation.

What counts as a trend? Which sources are trustworthy? How recent should the information be? What happens if a claim cannot be verified?

A better prompt provides clear instructions.

It defines the research window, sources, evaluation criteria, writing style, and required output.

But even a carefully written prompt has limitations.

If the task involves multiple searches, external documents, tool calls, and intermediate decisions, the AI system must manage information over time.

That introduces problems that wording alone cannot solve.

Context management is becoming critical

Every language model operates within a context window.

That window contains the instructions, conversation history, retrieved information, and other data the model can use when generating its next response.

Long-running agents can accumulate enormous amounts of context.

A research agent might read dozens of articles, inspect GitHub repositories, compare release notes, and generate multiple drafts.

Eventually, the system needs to decide which information to keep and which information to summarize or discard.

This process is often called context compaction.

The difficulty is that not all information has equal importance.

Imagine an agent working on a financial report.

It may have accumulated hundreds of messages, but one early instruction says that all monetary figures must be converted into euros using a specified exchange-rate date.

If the context compaction process drops that requirement, later calculations could become inconsistent.

The model might still produce a convincing report.

It would simply be following an incomplete version of the original task.

That’s why I find the recent Deep Agents updates interesting.

The November 5 changelog includes a fix for summarization cutoff handling and improvements to subagent tracking.

These are implementation-level changes, not proof that context problems have been solved.

But they illustrate how much engineering attention is now being directed toward maintaining reliable behavior across longer workflows.

Agent Skills: Turning prompts into reusable tools

Another development is the growing popularity of Agent Skills.

Instead of writing the same detailed instructions repeatedly, developers can package workflows into reusable files and supporting resources.

For example, imagine creating a skill called technical-article-review.

Its instructions could define how an agent should inspect an article, verify technical claims, check references, and prepare editorial feedback.

The skill could be reused across different projects.

That sounds simple, but it changes how prompts are managed.

Rather than treating every prompt as an isolated conversation, teams can organize instructions as version-controlled project assets.

Changes can be reviewed. Examples can be maintained. Common procedures can be standardized.

GitHub currently shows substantial attention around public collections of agent skills, including repositories maintained by Anthropic and Google.

The interesting part isn’t necessarily the number of stars.

It’s the idea that instructions themselves are becoming part of the software development workflow.

Of course, that creates a new responsibility.

A downloaded skill is not automatically trustworthy just because it comes from a popular repository.

A practical example: A research prompt that can be reused

Consider a simple research assistant.

Instead of asking it to find interesting news, we could define a repeatable process:

ROLE

You are a technical research analyst.

OBJECTIVE

Identify five important developments from

the last 72 hours.

RESEARCH RULES

• Prefer primary sources.
• Verify publication dates.
• Separate confirmed facts from analysis.
• Do not invent metrics or quotations.
• Label missing information.

EVALUATION

Score each development from 0 to 100:

• Innovation: 25
• Practical usefulness: 25
• Momentum: 20
• Audience relevance: 15
• Editorial potential: 15

OUTPUT

Return:

1. Five ranked developments
2. Direct source links
3. Three article ideas
4. Open verification questions

If evidence is insufficient, say so.

This is an illustrative prompt template, not a benchmarked solution.

Its main advantage is that the task becomes easier to understand, review, and repeat.

However, the prompt doesn’t guarantee access to current information.

If the AI system has no browsing capability, it cannot independently verify what happened during the last 72 hours.

Similarly, telling a model not to invent sources does not eliminate hallucinations.

Those limitations must be addressed through tooling, source validation, and evaluation.

Structured outputs: When the answer becomes data

Another important development is the increasing use of structured outputs.

For casual conversations, a well-written paragraph is often enough.

For automation, however, free-form text can be difficult to process reliably.

Imagine an application expecting a list of researched projects.

If the model returns different headings and formats every time, downstream software may struggle to extract the information.

A structured output contract provides a clearer interface.

For example:

{

„project“: „Example Project“,

„source_url“: „https://example.com“,

„innovation_score“: 20,

„verified“: false,

„open_questions“: [

„Is the license confirmed?“

]

}

This example is a proposed data structure, not a real research result.

An application could validate that the score is within an allowed range, that required fields exist, and that the result follows the expected schema.

With supported model APIs, structured-output features can also constrain the generated response.

But there’s an important distinction.

Valid JSON does not mean valid information.

A model can produce a perfectly formatted object containing an incorrect release date or an invented benchmark.

Schema validation solves a formatting problem.

Factual verification remains a separate responsibility.

Why prompt injection changes everything

As AI agents gain access to tools, security becomes more important.

A traditional chatbot might read an untrusted webpage and produce a misleading answer.

An agent with tool access might do something more consequential.

It could attempt to read files, send information to an external service, or modify data.

Prompt injection occurs when instructions embedded in untrusted content influence the model’s behavior.

Recent security research shows that attacks can target more than the model’s final response.

CrowdStrike’s updated prompt-injection taxonomy describes techniques designed to manipulate how agents plan their tasks.

Check Point Research has also documented cases where third-party agent configurations could persistently influence future outputs.

These findings highlight a fundamental problem.

An agent may encounter instructions inside a document that look relevant to its task but actually come from an untrusted source.

Simply adding “ignore malicious instructions” to the system prompt isn’t a complete defense.

Security controls need to exist outside the model.

Tool permissions, approval requirements, argument validation, and restricted access are all important.

A prompt can describe the rules.

The surrounding application must enforce them.

Prompt evaluation: The missing discipline

One of the biggest weaknesses in everyday prompt engineering is the lack of systematic testing.

Someone writes a prompt, runs it once, likes the result, and assumes the prompt works.

But what happens when the input changes?

What if a document is incomplete? What if a source contradicts another source? What if the agent encounters a malicious instruction?

A reliable workflow needs test cases.

For a research assistant, those could include:

• A genuine recent announcement with a clear primary source.
• An old article presented as breaking news.
• A repository with an unclear license.
• Two sources reporting different numbers.
• A webpage containing instructions intended to redirect the agent.

The system should be evaluated against expected behavior.

Did it verify the date? Did it identify the conflicting claims? Did it refuse to invent missing information? Did it keep untrusted content from controlling its tools?

This is where agent traces become useful.

Instead of examining only the final answer, developers can inspect intermediate steps and tool interactions.

That makes it easier to identify whether a failure originated in the prompt, retrieval process, tool configuration, or model behavior.

The goal is not to create a perfect prompt.

It’s to create a workflow that can be improved through evidence.

My take: Prompts are becoming software components

What I find interesting about these developments is how closely prompt engineering is beginning to resemble traditional software engineering.

We now have reusable instruction files, version control, structured interfaces, evaluation frameworks, and security requirements.

The prompt itself remains important.

Clear instructions, good examples, and well-defined objectives still make a difference.

But for serious applications, they’re only one part of the system.

If I were building a new AI workflow today, I would focus on five things.

First, define the task and its success criteria.

Second, provide reliable access to the information the model needs.

Third, make the expected output explicit and machine-checkable.

Fourth, restrict what the agent is allowed to do.

And finally, test the workflow against realistic failures before trusting it with important tasks.

That’s a less glamorous approach than discovering a secret prompt formula.

But it’s also much more useful.

The next stage of prompt engineering isn’t about convincing AI to behave intelligently through increasingly elaborate instructions.

It’s about building systems in which intelligent behavior can be checked, constrained, and improved.

And that may be the most important prompting trend of all.

---

Sources

• LangChain Deep Agents — Changelog
• Anthropic — Agent Skills
• Google — Agent Skills
• CrowdStrike — Prompt Injection and Agent Planning
• Check Point Research — Prompt Adware
• OpenAI — Safety in Building Agents

Editorial disclosure: This article is based on public documentation, release notes and security research. The example prompts are illustrative and have not been independently benchmarked.