Building agentic AI applications with a problem-first approach means writing the failure down before writing any code. You name a task that burns real hours or real money, and you measure how often it goes wrong today. Only then do you ask whether an agent, meaning a language model that plans and calls tools in a loop, is the cheapest fix. Most agent projects run this order backwards: the demo comes first and the search for a matching problem comes second. The quiet shelving follows about four months later.
This article walks the sequence in order, from naming what you are building to the governance bill that arrives when it ships.
AI agent vs agentic AI: name the thing before you build it
An AI agent is a system in which a language model decides its own next step. It reads a goal and picks a tool, then inspects the result and repeats until the job is done or the budget is gone. Agentic AI is the broader property: the degree to which any system directs itself. The distinction matters because vendors sell the two words interchangeably.
Anthropic's guide to building effective agents draws the line between workflows, where your code decides the path and the model fills in the steps, and agents, where the model decides the path itself. The guide's core advice is restraint: add agentic complexity only when a simpler solution demonstrably falls short, because autonomy trades cost and latency for flexibility.
A problem-first team turns that into a sorting test. If the path through the task is known in advance, build a workflow. If the path only reveals itself at runtime, and the value of the task covers the extra tokens, you have earned an agent. Plenty of products marketed as agents are workflows in a trench coat, which is fine. Workflows ship.
Principles of building AI agents, starting from the problem statement
The plain version: describe the failure you are removing in one sentence a finance director would understand, and attach a number to it.
"Support spends 40 hours a week routing tickets a reader could route in seconds" is a problem statement. "We should be doing something with agents" is a mood. The first version hands you the baseline to beat and the point where you are allowed to stop.
Three principles fall out of a real problem statement:
- Define done in numbers. An agent that "helps with tickets" can never fail, which also means it can never succeed.
- Grant the smallest autonomy that solves the problem. Every tool you add is new surface area for the model to get creative in, and you will discover its creativity at 2 a.m.
- Build the evaluation before the agent. If an output cannot be scored automatically, you will be grading homework by hand for the rest of the project.
Measuring the baseline sounds bureaucratic until it saves you. A team that knows humans route tickets with 96 percent accuracy knows an agent scoring 89 is a regression wearing a novelty hat. A team that never measured will ship the regression and call it transformation.
The whiteboard hour where the problem sentence gets written is the highest-leverage hour of the build. It is also the hour most teams skip, on the grounds that the framework tutorial looked easy enough.
AI agent frameworks come last, and many problems need less than one
A framework is a bundle of opinions about orchestration. You cannot evaluate opinions about orchestration until the problem has told you what needs orchestrating.
A single agent with a handful of tools is a loop around an API call, and the model provider's SDK covers it without help. Heavier orchestration earns its keep when the problem itself splits into roles with separate contexts, or when subtasks genuinely run in parallel. Choosing the framework first inverts the dependency: the architecture arrives before the requirements, and the requirements get bent until they fit it.
There is also a churn tax. The agent framework ecosystem reinvents itself roughly once per funding cycle, and code written against a thin loop migrates in an afternoon while code written against a deep abstraction migrates in a quarter. Most of the engineering effort lives outside the model anyway, in the glue and plumbing covered in the AI systems engineering problem nobody budgets for.
A practical test when you do evaluate a framework: rebuild your smallest working agent inside the candidate in a day. If the port takes longer than the original build, the abstraction is charging more than it earns. The problem statement is what makes this test runnable, since a team without one has no smallest working agent to port, only a demo with ambitions.
AI agent examples where the problem came first
The agents that reach production share a shape: a narrow scope and a boring domain, with a baseline you can measure.
An accounts team lets an agent code invoices against historical patterns and escalate the ambiguous ones. A support desk lets an agent draft replies that a human approves with one click. Neither demo wins a keynote, and both pay for themselves within a quarter. A broader tour of the pattern is in our guide to agentic AI use cases.
The ceiling is worth respecting. TheAgentCompany, a benchmark that drops agents into a simulated software firm with real tools and coworkers, found the most competitive agent completed 30 percent of realistic workplace tasks autonomously. Read as a promise of digital employees, that number is bleak. Read problem-first, it is a map: the tasks agents did complete were short-horizon and verifiable, which is exactly the territory a good problem statement aims at. The long-horizon remainder is where demos go to be quietly shelved, and where the agentic AI vendor landscape makes its boldest claims.
The AI governance problem arrives the day the agent ships
Once an agent acts on production systems, a named person owns its actions. Deciding who that person is takes longer than most technical steps, so start early.
A problem-first build keeps governance tractable because the problem statement already bounds what the agent touches. Three artefacts should exist before launch:
- An autonomy boundary: the actions the agent may take alone, and the actions that require human sign-off.
- An audit log of every tool call, kept where the owner can read it without asking engineering.
- A kill switch a human can reach faster than the agent can act again.
These are cheap on day one and very expensive to retrofit after an incident. For the organisational half of the question, written for the leaders who will own those boundary decisions, Agentic AI in Business treats governance as a design input.
A problem-first checklist you can run this week
Before any framework gets installed, answer these in writing:
- What failure are we removing, and what does it cost per month?
- What baseline does a human achieve today?
- Can an output be scored automatically? If no, what proxy comes close?
- Is the path through the task knowable in advance? If yes, build a workflow.
- What is the smallest set of tools that solves it?
- Who owns the agent's actions, and how do they turn it off?
If the answers hold up, the engineering that follows is well mapped. Agentic AI Engineering by Hyun Erwin walks the build itself, from reasoning loops and tool design through to single- and multi-agent systems in Python, and it assumes you arrive holding a problem statement. Arrive holding one. The trench coat is optional.