In the previous article, we wrote about being a developer in the age of AI and why agentic engineering does not remove the need for fundamentals. AI agents can write code, inspect files, run commands, summarize research, and automate parts of product development. But they still need direction.

This follow-up is about the next practical question.

How do you get better results from AI agents?

The common answer is usually: write better prompts.

That is not wrong, but it is incomplete. Prompt engineering matters, but the best AI agent results rarely come from one perfect prompt. They come from the operating system around the agent: the goal, the context, the tools, the memory, the feedback loop, the verification process, and the human judgment behind the work.

If an AI agent keeps producing generic, incorrect, or fragile output, the model may not be the only problem. Often, the agent is missing the same things a human teammate would need: clear instructions, access to relevant information, examples of good work, constraints, tools, and feedback.

AI agent performance is not mainly a magic prompt problem. It is a workflow design problem.

Why AI agents fail

AI agents can feel inconsistent. One day they help you build a useful prototype in minutes. The next day they misunderstand a simple requirement, over-engineer a solution, or confidently explain something that is wrong.

That inconsistency usually has patterns.

AI agents fail when:

The goal is vague.
The agent does not have enough context.
The task is too large.
The constraints are missing.
The agent cannot access the right files, tools, or documents.
There is no feedback loop.
Nobody checks whether the result is actually correct.
The agent is asked to make decisions that should belong to a human owner.

This is not unique to AI. A human developer, designer, marketer, or assistant would also struggle with vague instructions and missing context.

If you tell a person, "build me a dashboard," they will ask follow-up questions. What kind of dashboard? For whom? Which data? Which design system? Which device sizes? What should happen when data is missing? What does success look like?

AI agents often try to answer anyway. That is part of their usefulness and part of their danger. They fill gaps with assumptions.

Better AI agent performance starts by reducing the number of assumptions the agent must invent.

Better prompts are only the starting point

Prompt engineering means giving the AI clearer instructions. For non-technical readers, a prompt is simply the task description you give to the AI.

A weak prompt says what you want in broad terms.

Build me a dashboard.

A stronger prompt gives the agent context, constraints, and success criteria.

Build a dashboard for a SaaS founder to track monthly recurring revenue, churn, active users, failed payments, and support tickets. Use the existing design system. Do not add new dependencies. First inspect the current frontend structure and propose a plan. After implementation, run the relevant checks and list assumptions, risks, and missing data.

The second prompt is better because it reduces ambiguity.

It tells the agent:

Who the user is.
What the output should contain.
Which constraints matter.
What to do before implementation.
How the work will be judged.
What to report afterward.

Good prompts often include seven ingredients:

Goal: What should be achieved?
Audience: Who is this for?
Context: What should the agent know before acting?
Constraints: What should the agent avoid?
Examples: What does good output look like?
Acceptance criteria: How will success be evaluated?
Review request: What should the agent explain before or after the work?

Prompt engineering is useful, but it has a limit. If the agent does not know your product, your customers, your codebase, your business model, or your previous decisions, even a well-written prompt can only go so far.

Context is the real performance multiplier

Context is the information an agent needs to do the job well.

For a human teammate, context might include product goals, customer feedback, technical documentation, design rules, previous decisions, examples, and business constraints. AI agents need the same kind of information.

The less context you provide, the more the agent guesses.

For founders, context might include:

The target customer.
The problem being solved.
The current stage of the company.
The difference between prototype code and production code.
Important business constraints, such as budget, speed, compliance, or time to market.
Existing product decisions that should not be reopened casually.

For developers, context might include:

Project structure.
Coding conventions.
Architecture decisions.
Test commands.
API contracts.
Database models.
Security requirements.
Examples of similar existing code.

For content, marketing, and operations teams, context might include:

Brand voice.
Customer personas.
Previous campaigns.
SEO targets.
Legal constraints.
Examples of approved work.

This is why project documentation becomes more important in the age of AI agents, not less important. Documentation is not just for humans anymore. It is also fuel for AI systems.

If your company knowledge only exists in people's heads, your AI agents will not be able to use it reliably. If your product decisions are undocumented, the agent will reopen them. If your coding conventions are implicit, the agent will invent its own.

Good context turns an AI agent from a generic assistant into something closer to a useful teammate.

Refining is where quality comes from

Many people judge AI agents by the first answer they produce. That is a mistake.

The first answer is often a draft. Quality comes from refinement.

Refining means giving feedback, asking for alternatives, forcing tradeoffs into the open, and improving the result step by step.

Useful refinement prompts include:

What assumptions did you make?
What could go wrong with this approach?
Give me a simpler version.
Compare two possible solutions and recommend one.
What did you not verify?
Which parts are risky for production?
What would you ask before implementing this?
Rewrite this for a non-technical founder.
Rewrite this for a senior engineer.
Find edge cases we may have missed.

This is especially important for founders and non-technical teams. You may not know whether the code is good, but you can still ask the agent to expose assumptions, explain tradeoffs, and separate facts from guesses.

For technical teams, refinement should include inspecting the actual output: reading diffs, checking tests, reviewing logs, and validating behavior. Agent summaries are useful, but they are not proof.

The best AI workflows are not one-shot conversations. They are loops:

Give the task.
Review the plan.
Let the agent act.
Inspect the output.
Give feedback.
Verify the result.
Capture what should be reused next time.

That loop is where agentic engineering becomes a serious practice instead of a productivity trick.

RAG: giving agents the right knowledge

RAG stands for Retrieval-Augmented Generation.

In plain English, RAG means the AI can search relevant information before answering. Instead of relying only on what the model already knows, the agent retrieves documents, code, tickets, policies, or other data and uses that information to produce a better answer.

RAG can help an AI agent answer questions like:

What does our refund policy say?
Which API endpoint handles user invitations?
What did we decide about pricing last quarter?
Which customer complaints mention onboarding?
What are the security requirements for this feature?
Which previous blog posts should this article link to?

For founders, RAG matters because it turns company knowledge into usable leverage. If your pitch notes, customer interviews, product specs, and support conversations are searchable, AI agents can help you find patterns faster.

For developers, RAG matters because the agent can search the codebase, documentation, architecture records, API references, and issue history before suggesting a change.

For non-technical teams, RAG matters because it reduces the need to repeat context manually. The agent can retrieve the right background information at the right time.

But RAG is not magic.

Bad documents create bad answers. Outdated documentation creates outdated recommendations. Messy knowledge bases create messy retrieval. If the source material is weak, the AI may become confidently wrong with citations.

The practical lesson is simple: if you want better AI agents, improve the knowledge they retrieve.

Tools, plugins, MCP servers, skills, subagents, and LSP servers

The next step beyond prompts and context is tooling.

A basic chatbot can answer. An agent with tools can act.

Tools let AI agents do things such as search files, run tests, inspect logs, query databases, fetch web pages, create tickets, call APIs, or generate reports. This changes the agent from a text generator into a worker inside a controlled environment.

Here is a practical glossary.

Concept	Simple meaning	Why it improves AI agents
Prompt engineering	Better task instructions	Reduces ambiguity and improves first drafts
Context	Relevant background information	Reduces guessing and generic output
RAG	Searching trusted knowledge before answering	Gives the agent current, specific information
Tools	Actions the agent is allowed to perform	Lets the agent inspect, test, fetch, and change real systems
Plugins	Packaged capabilities added to an AI environment	Makes specialized functions easier to reuse
MCP servers	Standard bridges between AI agents and external systems	Lets agents connect to tools, files, APIs, databases, and services in a consistent way
Skills	Reusable instructions and workflows for specific tasks	Makes agent behavior more consistent and specialized
Agents	AI workers that can plan and act toward a goal	Handles multi-step tasks instead of single replies
Subagents	Specialized agents used for focused parts of a task	Splits complex work into research, implementation, review, testing, or debugging
LSP servers	Language intelligence for code editors and tools	Helps agents understand code structure, types, references, errors, and symbols

The important point is not the terminology. The important point is what each layer solves.

Prompts improve instructions. Context improves understanding. RAG improves knowledge access. Tools improve action. Skills improve repeatability. Subagents improve focus. LSP servers improve code awareness. Verification improves trust.

Better agents are not just smarter chat windows. They are connected to better systems.

The AI agent performance stack

If we want a practical model for improving AI agent performance, we can think in layers.

1. Intent

What are we trying to achieve?

The agent needs a goal that is specific enough to act on. "Improve the product" is too vague. "Reduce onboarding drop-off by simplifying the account setup flow" is better.

2. Context

What does the agent need to know?

This includes product background, users, business rules, codebase conventions, previous decisions, examples, and constraints.

3. Constraints

What should the agent avoid?

Examples include: do not add dependencies, do not change the public API, do not store personal data, do not change the design system, do not make production changes without review.

Constraints prevent agents from solving the right problem in the wrong way.

4. Tools

What can the agent use?

An agent that can inspect files, run tests, search documentation, or call an API can produce more grounded work than an agent that can only guess from a prompt.

5. Memory and retrieval

What should the agent remember or retrieve?

This is where RAG, documentation, knowledge bases, previous decisions, and examples become useful.

6. Feedback

How does the agent learn what good looks like in this context?

Feedback can be direct comments, reviewed examples, failed tests, edited drafts, or explicit correction.

7. Verification

How do we know the result is correct?

Verification can include tests, linting, manual review, security checks, analytics, user testing, or comparison against acceptance criteria.

8. Accountability

Who owns the outcome?

The agent can produce work. It cannot own the consequences. A human or team must decide what is safe to ship, publish, automate, or rely on.

This is the AI agent performance stack:

Intent
Context
Constraints
Tools
Memory and retrieval
Feedback
Verification
Accountability

If your AI agent is underperforming, do not only ask, "Which model should we use?" Ask which layer of the stack is weak.

What founders should do

For founders, AI agents are powerful because they reduce the cost of exploration. You can test ideas, write content, create prototypes, analyze customer feedback, automate operations, and prepare investor materials faster than before.

But speed can hide risk.

Founders should focus less on becoming prompt hackers and more on building better decision and documentation habits.

Practical steps:

Write short product specs before asking agents to build.
Keep a simple decision log for important product and technical choices.
Document your customer personas, pricing assumptions, and business constraints.
Separate prototype work from production work.
Ask agents to explain risks in plain language.
Get experienced technical review before users depend on the software.
Use agents to accelerate learning, not to avoid understanding.

A founder does not need to become a senior engineer to benefit from AI agents. But if the business depends on software, the founder needs enough technical literacy to know when to slow down and ask for help.

The dangerous question is: "Can AI build this for me?"

The better question is: "What context, review, and safeguards do we need so AI can help us build this responsibly?"

What developers should do

For developers, AI agents are becoming part of the engineering environment. The advantage will not go to developers who refuse to use them, and it will not go to developers who trust them blindly.

The advantage will go to developers who can design reliable agent workflows.

Practical steps:

Keep project documentation close to the code.
Write clear task descriptions with acceptance criteria.
Ask agents to inspect before implementing.
Split large work into small, reviewable tasks.
Use tests, linters, type checks, and build commands as verification tools.
Ask agents to list assumptions, risks, and alternatives.
Use subagents for research, implementation, testing, debugging, and review when the task is complex.
Treat generated code like code from a junior teammate: useful, but still reviewed.
Capture successful prompts and workflows as reusable skills or playbooks.

The future developer is not just a coder and not just a prompt writer. The future developer is a system designer for human-AI collaboration.

A practical checklist for better AI agent results

Before starting an AI agent task, ask:

Is the goal specific?
Is the task small enough?
Did I define who the output is for?
Did I provide relevant context?
Did I include constraints?
Did I define success criteria?
Does the agent have access to the right tools or documents?
Should the agent ask questions before acting?

During the task, ask:

Did the agent inspect the relevant context?
Did it make assumptions?
Did it choose the simplest reasonable approach?
Did it explain tradeoffs?
Did it avoid unnecessary complexity?

After the task, ask:

Did I review the actual output, not just the summary?
Did tests or validation run?
Are risks and edge cases visible?
Is sensitive data protected?
Can this be maintained later?
Should this workflow be documented for reuse?

If several answers are "I do not know," the next step is not to trust the agent more. The next step is to improve context, reduce scope, verify the output, or get human review.

The real skill is designing the environment

AI agents are improving quickly. Models will get better. Tools will get better. Agent frameworks will get better. But the basic lesson will remain: agents perform best when they operate inside a well-designed environment.

That environment includes clear goals, good documentation, retrieval, tools, feedback, tests, and accountable humans.

Better prompts help. But better prompts alone are not enough.

The teams that get the most value from AI agents will not be the teams with the cleverest prompt tricks. They will be the teams with the best context, the best workflows, the best review discipline, and the clearest understanding of what should remain a human decision.

That is the practical heart of agentic engineering.

It is not about replacing judgment with automation. It is about using automation inside a system where judgment still matters.

If you are interested in AI-assisted development, agentic workflows, practical product engineering, and the future of software teams, subscribe to the Pyango newsletter for more essays and experiments from our work.

Want to learn development in the AI-native era?

AI agents can help you move faster, but they work best when you understand the fundamentals behind the work: logic, data, APIs, debugging, testing, and technical judgment.

That is one of the reasons we are building TomorrowDev: a practical learning path for people who want to become developers in a world where AI is already part of the workflow.

If you want to follow the journey, see updates, and learn more about how we think about developer education, follow TomorrowDev on LinkedIn: TomorrowDev

How to Get Better Results from AI Agents: A Practical Guide to Context, Tools, and Agentic Workflows

Latest blogs