From Prompt Engineer to Agent Engineer: The 7 Skills That Actually Matter

The Identity Crisis in Tech

People call themselves prompt engineers. That made sense two years ago when the job was mostly about crafting clever instructions for a GPT model. But agents have changed the game.

An agent isn't just answering questions. It's doing things — booking flights, processing refunds, querying databases, making decisions. When you're building something that takes real actions in the real world, writing good prompts is just the bare minimum.

1. System Design

When you're building an agent, you're not building a single thing. You're building an orchestra. An LLM making decisions. Tools executing actions. Databases storing state. Maybe multiple models or sub-agents handling different tasks. Somehow all of these pieces need to work together without stepping on each other.

This is architecture. How does data flow through your system? What happens when one component fails? How do you handle a task that requires coordination between three different specialists?

If you've designed a back-end system with multiple services talking to each other — congratulations, you already speak this language. If you haven't, this is the first thing to learn. Agents aren't magic. They're software. And software needs structure.

2. Tool and Contract Design

Your agent interacts with the world through tools. Every tool has a contract: give me these inputs and I'll give you this output. If that contract is vague, your agent will fill in the gaps with imagination. And LLM imagination is not what you want when you're processing financial transactions.

Tight types. Concrete examples. Required fields. This is the highest-leverage fix most agents need.

3. Retrieval Engineering

Most production agents use RAG — Retrieval Augmented Generation. Instead of relying on what the model memorised during training, you fetch relevant documents and feed them into the context. That sounds simple. It's really not.

The quality of what you retrieve determines the ceiling of your agent's performance. If you feed it irrelevant documents, it will confidently answer using irrelevant information. The model doesn't know the context is garbage — it just does its best with what you gave it.

• Chunking: Too big and important details get diluted. Too small and you lose context.
• Embedding model: Are similar concepts actually landing near each other in vector space?
• Re-ranking: A second pass that scores results by actual relevance and pushes the good stuff to the top.

Some people spend entire careers on retrieval alone. You don't need to master it overnight — but you need to know it exists and understand the basics.

4. Reliability Engineering

Agents make API calls. APIs fail. External services go down. Networks time out. Your agent can get stuck waiting for a response that's never coming, or retry the same failing request forever. Does that sound familiar? These are the exact problems backend engineers have solved for decades.

If you have backend experience, you already know this playbook. If you don't — most people building agents right now are learning these lessons the hard way in production.

5. Security and Safety

Your agent is an attack surface. People will try to manipulate it.

Beyond attacks, there's just good hygiene. Does your agent really need write access to that database? Should it be able to send emails without approval? What happens if it tries to do something dangerous because it misunderstood the request?

• Input validation — catch malicious or malformed requests before they reach the model.
• Output filters — block responses that violate policy.
• Permission boundaries — limit what the agent can even attempt.

The threat model is different from traditional software. But the mindset is the same.

6. Evaluation and Observability

Remember this phrase: you cannot improve what you cannot measure.

When your agent breaks — and it will break — you need to know exactly what happened. Which tool was called with what parameters? What did the retrieval system return? What was the model's reasoning? Without this, debugging is guesswork.

• Tracing — every decision logged, every tool call recorded. A complete timeline of what your agent did and why.
• Evaluation pipelines — test cases with known good answers, metrics like success rate, latency, and cost per task.
• Automated regression tests — catch issues before they ship.

7. Product Thinking

This one's easy to overlook because it's not technical. It might be the most important.

Your agents exist to serve humans. Humans have expectations. They want to know when the agent is confident versus uncertain. They want to understand what it can and can't do. They need graceful handling when things go wrong — not a cryptic error message.

• When should the agent ask for clarification?
• When should it escalate to a human?
• How do you build trust so people actually use it for real work?

The same agent might nail a task one day and fumble it the next. This is UX design for systems that are inherently unpredictable. Agent engineers think about the human on the other end — not just the code.