Prompt Engineering After Agents: The Skills That Still Matter Most

Agents Have Not Eliminated Prompt Engineering

The arrival of AI agents has encouraged a seductive claim: once models can plan, browse, call tools and revise their work, prompt engineering becomes obsolete. The opposite is closer to the truth. Autonomy increases the number of decisions an AI system can make, which increases the number of ways it can fail. A chatbot given one question may produce one poor answer. An agent given access to email, customer records and payment tools may make a chain of plausible but damaging choices before anyone notices. The engineering task therefore shifts from polishing isolated prompts to designing the conditions under which decisions are made.

That shift changes the unit of work. A production agent is not governed by a single clever instruction but by a stack: system policies, user intent, retrieved context, tool descriptions, examples, memory, approval rules and evaluation logic. Each layer competes for the model’s attention. A vague tool description can undermine a precise system prompt; stale retrieved data can override sound general knowledge; an ambiguous success criterion can cause an agent to optimise the wrong outcome. The enduring skill is not finding magic words. It is making intent legible, constraints enforceable and errors observable across the whole system.

Clear Instructions Still Define the Operating Boundary

Agents need explicit objectives because broad goals conceal tradeoffs. Telling a procurement agent to “reduce software costs” leaves unanswered whether it may cancel contracts, downgrade licences, contact vendors or expose usage data during negotiation. A stronger instruction defines the target, scope and limits: identify annual savings above £10,000, preserve security-critical tools, prepare recommendations for finance, and do not execute changes without approval. The agent now has an operating boundary rather than a slogan.

Good instructions separate requirements from preferences. “Never send a refund above £500 without human approval” is a hard constraint; “prefer the customer’s original payment method” is a policy preference; “use a warm tone” is a stylistic choice. When these are blended into one block of prose, models may treat them as equally negotiable. Numbered rules, explicit priorities and definitions of ambiguous terms make conflicts easier to resolve. If speed and accuracy collide, the prompt should state which wins and under what circumstances.

Specificity has costs. An instruction set that anticipates every edge case becomes long, brittle and difficult to maintain. Excess detail can also distract the model from the central task. Effective teams write the smallest policy that reliably governs common and high-risk cases, then enforce critical restrictions outside the model through permissions, validation and approval gates. Prompting should guide behaviour; it should not impersonate access control.

Context Design Is the New Core Discipline

An agent’s quality depends heavily on what it sees at the moment of decision. Context design means selecting, ordering and labelling the information that enters the model’s working window. More context is not automatically better. Feeding an agent 200 pages of product documentation may reduce accuracy if the relevant cancellation rule is buried beside obsolete policies. Retrieval should favour authoritative, current and task-specific material, with metadata such as publication date, jurisdiction and document owner made visible.

Consider an insurance agent assessing a travel claim. It may need the customer’s policy version, dates of travel, cause of disruption, previous correspondence and applicable exclusions. It probably does not need the customer’s full ten-year account history. A useful context packet might contain five short records totalling 6,000 tokens rather than a 60,000-token archive. That choice lowers latency and cost while reducing contradictions. Where documents disagree, the system should rank sources explicitly: signed policy terms above help-centre summaries, and current endorsements above the original schedule.

Memory requires similar discipline. Persistent memory can personalise an agent, but it can also preserve mistakes and sensitive information. A note such as “customer prefers email” is relatively safe; “customer is difficult and unlikely to complain” is subjective, potentially discriminatory and operationally dangerous. Teams should define what may be remembered, for how long, from which source and with what confidence. Context is not a warehouse into which everything is poured. It is an edited briefing assembled for a particular decision.

Tool Schemas Are Prompts With Consequences

Every tool exposed to an agent carries an implicit instruction through its name, description, parameters and return values. A function called “close_account” invites a different interpretation from “request_account_closure”. If the first actually creates a pending review, the schema is misleading; if the second immediately deletes data, it is hazardous. Tool interfaces should describe what will happen, whether the action is reversible, what permissions apply and what confirmation is required.

Parameter design matters as much as prose. Free-text fields encourage improvisation, while constrained types narrow the error surface. A shipping tool should accept an ISO country code, a validated postal address and an enumerated service level rather than one unstructured string. A payment tool might require amount, currency, invoice identifier and idempotency key. The idempotency key is not cosmetic: without it, a retry after a timeout can charge a customer twice. The agent also needs structured error responses distinguishing validation failure, permission denial, temporary outage and unknown execution status.

The best tool sets are small and composable. Giving an agent 80 overlapping functions increases selection errors and consumes context. Consolidation, however, can produce oversized tools with dozens of optional parameters. Teams must balance discoverability against precision, often grouping tools by domain and exposing only those required for the current workflow. High-impact actions should be separated into prepare, review and execute stages. An agent may draft a bank transfer, but execution should require a fresh approval token rather than merely another sentence in the conversation.

Planning Matters, but Verification Matters More

Agent frameworks often emphasise planning: decompose the goal, choose tools, inspect results and continue. Planning is useful, especially for research or multi-system workflows, but a fluent plan is not evidence of correctness. Models can produce persuasive step-by-step strategies that rest on a false assumption. Production systems should therefore require verification at key transitions rather than trusting the coherence of the plan.

For a market-research task, the agent might be asked to identify the five largest UK energy suppliers by customer count. It should not simply browse five company pages and rank the numbers, because dates and definitions may differ. Verification criteria could require figures from the same reporting period, citations for every number and a note distinguishing electricity accounts from households. If two sources differ by more than 5 per cent, the agent should flag the discrepancy instead of averaging it away. These rules turn “research thoroughly” into observable behaviour.

Not every step deserves equal scrutiny. Requiring confirmation after each read-only search makes an agent slow and irritating; allowing unrestricted execution is reckless. A practical approach classifies actions by risk. Reading public data may proceed automatically. Editing an internal record may require validation and an audit log. Sending external communications may need review above a defined sensitivity threshold. Moving money, deleting data or changing access rights should face the strongest controls. Autonomy should expand where errors are cheap and contract where they are costly.

Evaluation Must Measure Outcomes, Not Eloquence

Traditional prompt testing often asks whether an answer looks good. Agent evaluation must ask whether the system completed the task correctly, complied with policy and used resources sensibly. A customer-support agent that writes polished replies but issues incorrect refunds is a failure. So is an accurate agent that takes 40 tool calls and three minutes to resolve a routine query. Useful scorecards combine task success, factual accuracy, policy compliance, latency, cost and human escalation rate.

A representative evaluation set should contain ordinary cases, edge cases and adversarial cases. For a returns agent, 500 test scenarios might include intact goods within the return window, damaged products, missing receipts, restricted items, duplicate requests and attempts to manipulate the model through text embedded in uploaded documents. Results should be segmented rather than collapsed into one average. A 96 per cent success rate can conceal a 20 per cent failure rate on high-value refunds, where the financial exposure is concentrated.

Automated judges can accelerate testing, but they should not be the sole authority. A model grading another model may reward plausible language or share the same blind spots. Deterministic checks should validate dates, totals, required fields and prohibited actions. Domain specialists should review samples of consequential decisions. Online monitoring should then compare test performance with real traffic, because production inputs are messier than curated benchmarks. Evaluation is not a launch gate passed once; it is the mechanism by which prompts, tools and policies remain trustworthy as models and data change.

Failure Handling Is Part of the Prompt

A capable agent must know what to do when it cannot proceed. “Try again” is not a failure strategy. Repeated retries can duplicate actions, amplify costs or trigger rate limits. Instructions should distinguish recoverable failures from uncertain and terminal ones. A temporary network error may justify two retries with exponential backoff. Invalid credentials require escalation. An unknown payment status requires reconciliation before any further charge is attempted.

Graceful failure also depends on calibrated communication. When evidence is incomplete, the agent should state what is known, what is missing and what action would resolve the uncertainty. It should not fabricate completion or bury caveats beneath confident prose. In a scheduling workflow, if the calendar tool times out after a meeting request, the agent should say that the booking is unconfirmed and check the calendar before retrying. That wording protects the user while the underlying control prevents duplication.

Human handoffs should transfer state rather than merely announce defeat. The reviewer needs the user’s goal, actions already taken, tool outputs, unresolved question and recommended next step. A concise handoff can save several minutes per case and prevent the human from repeating risky operations. Logs should preserve enough detail for audit without exposing unnecessary personal data. Failure handling is where abstract safety claims become operational behaviour.

The Durable Skill Is Systems Judgement

The most valuable prompt engineers increasingly look like product architects, policy writers and reliability engineers. They can translate a business goal into explicit decisions, determine which context is authoritative, design tools that resist misuse and define measurable acceptance criteria. They understand that model behaviour is probabilistic and build controls around that fact. The job is less about discovering a phrase that boosts performance by 2 per cent and more about deciding where a 2 per cent failure rate is unacceptable.

This work demands experimentation. Teams should version prompts, schemas and retrieval settings; record which model produced each result; and run regression tests before deployment. A change that improves completion by four percentage points may also add 30 per cent latency or double tool usage. Another may reduce false refusals while weakening privacy compliance. Those tradeoffs belong in release decisions, not in anecdotes from a handful of impressive demonstrations.

As agents become more capable, instructions may become shorter at the surface, but the surrounding design will become more rigorous. Clear objectives, curated context, precise tool contracts, risk-based approvals, outcome-focused evaluation and disciplined recovery remain the foundations. Agents do not make prompt engineering disappear. They expose its mature form: the engineering of decisions made by systems that can act.