Methodologies and Core Patterns
Five Core Shifts in the AI-Human Paradigm
Chapter 1 introduced agents as systems built around language models, not as models alone. This chapter looks at the working patterns that make those systems useful.
The patterns are not complicated. They are easy to miss because they do not look like traditional programming. You converse, inspect, revise, compare, preserve, and try again. The loop is simple, but its consequences are large.
Five shifts sit underneath that loop.
1. Stochasticity as a Source of Variation
Large language models are probabilistic systems. Given the same prompt, model, and settings, they may still produce different valid completions, especially when sampling is enabled. At first, that variation can feel like a flaw. For some tasks, it is.
If you need a total, a permission decision, a file path check, or a test result, randomness is a liability. Ordinary software should handle those parts.
But when you are exploring an idea, variation is useful. It can give you another framing, another analogy, another plan, another title, another critique, another way into the problem.
one intention
โ
many possible drafts
โ
selection and revision
This is one of the first methodological changes. You stop treating every variation as noise. You start asking which kinds of variation are valuable, which are dangerous, and where the system should be allowed to explore.
2. A Moving Platform
The models available to builders keep changing. Newer versions may have broader context windows, better tool-use behavior, stronger coding ability, lower cost, or different failure modes. The application around the model may also change: retrieval, memory, prompts, policies, tools, and orchestration can all be revised.
That does not mean your agent is magically improving during use.
It means you are building on a moving platform.
This has two consequences.
First, agent design should make replacement possible. If a better model becomes available, the system should not depend on one model’s quirks so deeply that upgrading breaks everything.
Second, you need version awareness. If behavior changes, ask what changed:
model version?
prompt?
tool schema?
memory?
retrieval policy?
temperature?
system instructions?
user preference?
Without that discipline, improvement and regression look the same: the system feels different, and nobody knows why.
3. Building at the Speed of Thought
Natural language shortens the path from intention to first artifact.
You can describe a tool, ask for a structure, generate examples, critique the result, and revise it without first translating everything into a formal specification. That makes early exploration much faster.
The speed is real, but it should be understood correctly. AI-assisted building compresses the beginning of the work. It does not remove the need for judgment, testing, taste, review, or maintenance.
fast:
sketch, scaffold, compare, explore
still hard:
verify, secure, simplify, maintain, decide
Agent methodology is therefore not “ask and accept.” It is a disciplined loop of generation and evaluation.
Those are different jobs. Generation is allowed to be expansive, surprising, and incomplete. Evaluation has to ask a narrower question: does this candidate satisfy the goal, respect the constraints, and deserve to replace the current version? If the same model, prompt, or role does both jobs without criteria, the loop can become agreement without evidence. A second opinion is useful only when it produces reasons, evidence requests, or a concrete comparison.
4. Creation for More People
When language becomes an interface, more people can participate in building.
A researcher can describe a data workflow. A teacher can ask for lesson variants. A writer can build an editorial assistant. A founder can sketch a prototype. A developer can move faster across unfamiliar libraries. The entry point shifts from syntax to intention.
That does not make every output correct. It changes who can begin.
The old bottleneck was often translation:
idea
โ
technical representation
โ
implementation
The new workflow can begin one step earlier:
idea
โ
conversation
โ
working representation
โ
implementation and review
The person still needs to decide what is good. In fact, that judgment becomes more important because the system can produce plausible wrong answers at speed.
5. Access to a Wider Field of Patterns
When you work with a language model, you are working with a system trained across many kinds of text. It can draw on patterns from programming, design, science, business, history, education, and everyday writing.
That does not mean it contains “the collective mind” in a literal sense. It does not know which training example supports which claim unless the surrounding system provides retrieval or citations. It can be confidently wrong.
Still, the practical effect is significant. A model can surface analogies, examples, terminology, and structures you might not have reached alone. It can help you search the space of possibilities.
The methodology is to treat those suggestions as candidates:
model suggests
โ
human inspects
โ
tools verify where needed
โ
system preserves what works
This keeps the energy of exploration without confusing generated text with established truth.
AI as a Medium
“The medium is the message.” – Marshall McLuhan
Every major communication medium changes more than transmission. It changes what people notice, what they make, and how ideas move.
Voice made memory and performance central. Print made durable distribution possible. Radio and television created shared mass experiences. The internet made publishing, searching, linking, and remixing part of ordinary life.
AI adds a new property: the medium can transform the message while you are creating it.
You do more than send a sentence through the system. You can ask the system to reframe it, critique it, summarize it, translate it, test it against a role, turn it into code, compare it with another version, or use it as the first step in a workflow.
That makes AI feel less like a channel and more like a working surface.
expression
โ
interpretation
โ
transformation
โ
feedback
โ
new expression
Conversation matters because it is not decoration around the work. For many agent systems, the conversation is where the work is shaped.
Evolving Together
Working with an agent is not the same as using a hammer, a spreadsheet, or a search box. Those tools may be powerful, but they usually wait for precise operation. An agentic system can respond to incomplete ideas, ask for clarification, propose next steps, and help maintain continuity across a task.
There is still a danger in the language here. The model is not becoming your friend, and it is not absorbing your identity. But the interaction can adapt.
Some adaptation happens inside the current context. The model responds to what you have already said in the session.
Some happens in the application. Preferences, files, summaries, and memories may be stored and retrieved later.
Some happens outside your system entirely. Model providers release new models, and the same prompt may behave differently.
From the user’s point of view, these mechanisms can blend together. From an architect’s point of view, they must be separated.
session context:
what the model can currently see
persistent memory:
what the application stores and retrieves
model update:
a new underlying dependency
human learning:
your own improved ability to steer the system
The collaboration improves most reliably when the human also improves: clearer goals, better examples, stronger review, sharper constraints, and a better sense of which tasks deserve automation.
The Feedback Loop Is the Methodology
The central method of this book is the feedback loop.
You give the system a goal. It produces something. You inspect the result. You correct, narrow, expand, reject, preserve, or redirect. The next step includes that feedback.
goal
โ
attempt
โ
observation
โ
feedback
โ
revision
โ
comparison
This is a way to get better outputs, but also a way to discover what you actually mean.
Often the first answer is useful because it is wrong in a revealing way. It exposes a missing constraint, an unclear audience, a hidden assumption, or a better direction. The value of the loop is that it makes those discoveries cheap.
The loop also gives agent systems their basic shape. Reflection, critique, memory, versioning, and multi-agent collaboration are all extensions of this pattern. They differ in what produces the feedback, what stores it, and who decides whether the revision is better.
Repeated agreement is not verification. If three agents all say the draft is strong, you have measured agreement among those agents, not truth. The loop becomes reliable when its feedback is anchored to something outside the immediate text: a rubric, a test, a source, a user decision, a saved version, or an observed result.
How to Think With Agents
Thinking with agents is a skill. It is not the same as typing a perfect prompt.
A good agent conversation usually moves through modes:
| Mode | What you say | What you want |
|---|---|---|
| Explore | “Show me three ways to approach this.” | Variation |
| Specify | “Use this audience, constraint, and format.” | Direction |
| Execute | “Now produce the draft/code/plan.” | Momentum |
| Critique | “Find the weak points.” | Pressure |
| Revise | “Improve it using that critique.” | Iteration |
| Preserve | “Keep this version and explain why.” | Memory and versioning |
The modes matter because they keep the interaction from becoming vague. If you ask for exploration, do not expect finality. If you ask for execution, provide constraints. If you ask for critique, decide who or what gets authority over the result.
Many agent frameworks formalize these patterns with roles, memory, tools, planners, critics, evaluators, or optimization layers. You do not need a framework to begin thinking this way, but frameworks become easier to understand once you recognize the underlying loop.
Be Yourself, But Give the System Handles
There is no single right voice for working with agents. Some people think aloud. Some prefer concise instructions. Some want options; others want direct execution. The best workflow should fit the person using it.
But “be yourself” does not mean “be vague.”
The system works better when you give it handles:
goal:
what you are trying to achieve
context:
what matters and what has already happened
constraints:
what must not change
examples:
what good looks like
role:
how the model should approach the work
feedback:
what was wrong with the last attempt
Those handles let the agent system adapt to your working style without pretending that it can read your mind.
What a Productive Agent Conversation Looks Like
There is no perfect prompt that unlocks everything. Productive conversations come from practice and structure.
A weak interaction often looks like this:
user:
Make this better.
agent:
Better in an unspecified way.
A stronger interaction gives the system something to work with:
user:
Rewrite this for a technical reader.
Preserve the claim.
Remove hype.
Keep it under 120 words.
Give me two options and explain the tradeoff.
Now the model can generate alternatives, and the human has a basis for comparison.
The goal is not to become a prompt engineer in the gimmicky sense. It is to become a better collaborator with a probabilistic system: clear when you need structure, open when you need exploration, strict when correctness matters, and willing to revise when the first attempt reveals something useful.
Teaching the Agent to Reflect
Reflection is one of the most useful patterns in agent work. The basic move is simple:
generate
โ
evaluate
โ
revise
For example:
Write a one-sentence mission statement for a company that wants
to have a meaningful, positive impact on the world.
Then evaluate it against three criteria:
- clarity
- specificity
- emotional resonance
Identify one weakness.
Rewrite the sentence to address that weakness.
Explain what changed.
The point is not that the model’s self-evaluation is automatically correct. It often is not. The point is that evaluation becomes visible. Once a critique is written down, you can inspect it, challenge it, ask another role to review it, or compare the original and revised versions yourself.
flowchart TD
A[Generate candidate]
B[Evaluate against criteria]
C[Identify weaknesses]
D[Propose revision]
E[Compare original and revision]
F{Is the revision better?}
G[Accept revision]
H[Keep original]
A --> B
B --> C
C --> D
D --> E
E --> F
F -->|Yes| G
F -->|No| H
Reflection becomes more useful when the criteria are explicit:
| Weak reflection prompt | Stronger reflection prompt |
|---|---|
| “Make it better.” | “Evaluate clarity, specificity, and audience fit.” |
| “Try again.” | “Revise only the weak verb and preserve the claim.” |
| “Is this good?” | “List two risks and one reason to keep the current version.” |
This is where the conversation begins to look like a system. There is a draft, a review, a revision, and a comparison. Later chapters will turn that pattern into roles, agent teams, memory, versioning, and larger architectures.
For now, the important lesson is enough:
Feedback is not an afterthought. It is the basic method for working with agents.