The “New Era of Software Engineering” is a three-part series exploring how AI is redefining software delivery. As code becomes automated, the real challenge shifts to clearly defining the right intent. We introduce the role of the Intent Engineer, share our Intent Engineering methodology, and provide hands-on insights from SQUER’s first dedicated Intent Engineer — outlining how engineering intent becomes the key capability in the age of AI.
In our previous article, we explained why SQUER created the Intent Engineer — a new role designed for an era where AI agents write the code. We described the shift from requirements to intents, the Focused Impact Pair model, and why the bottleneck in software delivery has moved upstream.
The response was clear: people understood why Intent Engineering matters. But the most common question was: how does it actually work in practice?
This article answers that question. It's based on our internal Intent Engineering Playbook — the methodology document we use to train Intent Engineers, on board new engagement teams, and ensure consistency across customer projects. We'remaking the core of this methodology public because we believe the industryneeds a shared language for this new way of working.
Why not just better requirements?
Before diving into the methodology, it's worth addressing the obvious objection: "Can't we just write better requirements?"No. And here's why.
Requirements describe solutions. "The system shall provide a REST endpoint that accepts claim submissions and validates mandatory fields against a JSON schema. "The solution is baked in. The architecture is decided. A human developer needed this precision because they needed to know exactly what to build. AI agents don't work that way. Give an agent a precise requirement, and it becomes a typist — faithfully translating your predetermined design into code. Give it an intent — the business problem, the context, the constraints, and the success criteria — and it has the freedom to make hundreds of intelligent micro-decisions. Field validation order, error handling, API design, data model choices. Decisions that previously required Slack threads and meeting invitations now happen autonomously, and correctly, because the agent understands the underlying purpose.
The difference isn't semantic. It's structural. Requirements over-constrain the solution space. User stories under-specify the problem space. Intent hits the sweet spot: precise about the what and why, deliberately open about the how.
The Intent hierarchy
The first question from anyone with an agile background: "Is an intent an Epic or a Story?" Neither. Intents follow their own hierarchy, and that's by design.
Strategic Intent maps roughly to an initiative or theme. It's a business goal at the quarterly or annual level. "Digitise claims processing." It sets direction but isn't actionable on its own.
Domain Intent is the work horse. It's a concrete, deliverable business outcome within a specific domain. "Automatically categorise incoming claims so they reach the right processing team within 15 minutes instead of 4.2 hours." A Focused Impact Pair can typically deliver a Domain Intent in one to four weeks.
Tactical Intent breaksdown complex Domain Intents into implementation units when needed."Implement document analysis and NLP-based classification for claims categorisation." This is what the Systems Engineer and AI agents work withdirectly.
The key difference to agile: intent granularity isn't driven by team capacity ("Does this fit in a sprint?"), but by business outcomes ("Does this solve a real problem?"). When AI agents can work autonomously for hours, the sprint-sized work unit becomes an artificial constraint.
Anatomy of an intent
Every intent — regardless of hierarchy level — follows a consistent structure with eleven fields. This isn't bureaucracy. Each field exists because it directly improves the quality of AI agent output.
The critical fields:
Business Context — Why does this matter? What's the cost of the current state? What business goal does this support? This is the field that separates an intent from a feature request. "Claims processing is the largest cost driver in operations. Each hour of processing time costs an average of €85."
Current State — How does it work today? This is where most of the value lives. When an Intent Engineer spends a morning shadowing a claims adjuster and discovers that 38% of incoming claims are incomplete, causing a 2.4-day delay per follow-up cycle — that's the kind of context that makes an AI agent dangerously effective. Concrete numbers. Actual workflows. Real friction.
Target State — What should be different after implementation? Described as an observable outcome, never as a feature. Not "a dashboard showing claim status" but team leads can identify critical cases requiring escalation before they become overdue."
Success Criteria — How do we measure success? Quantitative whenever possible. Categorisation accuracy ≥ 92%. Time from intake to team assignment < 15 minutes. Agent satisfaction ≥ 4/5.
Constraints — Non-negotiable boundaries. Regulatory requirements, organisational limitations, domain-specific rules. "GDPR: no customer data may leave the EU. Regulatory: final decision must remain with a human. Existing claim categories cannot be modified."
Domain Knowledge — Business terms, process descriptions, decision rules. The oxygen of AI-driven development. Without it, agents hallucinate. With it, they make decisions that would impress a domain expert.
What an intent deliberately does not contain: technology choices, UI specifications, architecture patterns, or implementation details. Those decisions belong to the Systems Engineer and the AI agents — informed by the platform's technology stack, architectural guardrails, and the domain knowledge from the intent.
How Intent Engineers discover intents
Intents aren't written at a desk. They're discovered in the field. The Intent Engineer's most important skill isn't documentation — it's listening, observing, and understanding.
Intent Interviews are structured conversations with business stakeholders, following seven core questions: What are you trying to achieve? Why does it matter for the business? How do you do it today? What frustrates you most about the current process? How would you know it's solved? What must absolutely not happen? Who else is affected?
The key: never ask "What would you like?" Ask about problems, goals, and context.
Process Shadowing means the Intent Engineer spends time with business staff during their daily work. Watching. Noting media breaks, manual workarounds, waiting times, system switches. The most valuable intents come from things people do, not things they say. Staff have normalised their workarounds — they don't even see them as problems anymore.
Domain Mapping visualises the domain together with the business department: processes, entities, decisionpoints, systems. Techniques like Event Storming or Domain Storytelling help identify intents at points where value is created or lost.
Data-Driven Discovery analyses existing data: error rates, throughput times, support tickets, escalation patterns. These data points validate intents quantitatively and help with prioritisation.
Reverse Discovery takes existing backlogs and clusters backwards. Which business goal sits behind these 47 user stories? Often, an entire feature backlog can be condensed into five to eight focused Domain Intents.
The art of reframing
The biggest danger in discovery: The business department delivers solutions instead of problems. This is natural— they've been trained by years of requirements workshops to say "We need a dashboard" instead of describing what decision they can't make today.
The Intent Engineer's job is to reframe:
When someone says "We need a dashboard," the Intent Engineer asks: "What decisions are you making today where you lack the data?" When someone says "This needs to be automated," the response is: "What exactly do you do manually? How often? What happens when it goes wrong?" When someone says "We need an interface to System X," the question is: "What information do you need, when, and why from System X? What do you do today instead?"
This reframing is perhaps the single most important skill in the Intent Engineer's toolkit. It's the difference between building what someone asks for and solving the problem they actually have.
Intent patterns
After working with intents across multiple engagements, we've identified six recurring patterns:
Automation Intents emerge when staff perform repetitive, rule-based tasks manually. Signal words: "Every time…", "Always…","Copy-paste…" Success criteria: time savings, error reduction, throughput increase.
Decision Support Intents appear when people make decisions based on incomplete or scattered information. Signal words: "We don't know…", "It depends…","I have to check first…" Success criteria: decision time, data quality, decision consistency.
Communication Intents arise when information needs to be translated or distributed from one context to another. "After every claim settlement, the customer must receive a comprehensible summary within 48 hours. Currently, adjusters write these manually."
Compliance Intents address regulatory requirements. Here, the constraints often become the main content. The Intent Engineer must precisely understand and document the regulatory requirement — domain knowledge is especially critical.
Integration Intents connect systems, data, or processes that currently operate in isolation. Danger zone: these tend to get technical quickly. The Intent Engineer must stay with the business problem. Not "API connection to System X" but "The adjuster needs the customer's current contract status during processing without opening System X separately."
Experience Intents improve user experience, internal or external. Success criteria can be NPS scores, usage rates, support ticket reduction, or time-on-task.
From intent to execution
The handoff between Intent Engineer and Systems Engineer follows a clear principle: the Intent Engineer owns the what and why, the Systems Engineer owns the how.
The handoff point is reached when the intent is fully documented, validated by the business department, domain knowledge is structured and available, success criteria are quantified, and open questions are resolved or explicitly marked as assumptions.
The Systems Engineer doesn't translate the intent into user stories. They translate it into an agent context: a structured description that gives AI agents everything they need for autonomous implementation. Architecture constraints, tech stack, code conventions, test requirements, quality gates. The agent combines this with the domain knowledge from the intent to produce code, tests, documentation, and infrastructure-as-code.
But the Intent Engineer's job doesn't end at handoff. The role shifts from discovery to validation: continuous demos with the business department, feedback loops checking whether results match the intent, intent refinement based on new insights, and outcome measurement after deployment.
The Intent Engineer isn't done when the intent is written. They're done when the business goal is achieved.
Anti-patterns: what goes wrong
We've identified five patterns that signal an intent is going off the rails:
The Disguised Requirement — "The intent is: a REST endpoint that accepts claim submissions and writes them to the database." That's not an intent. That's an implementation spec with a different label. Better: "Claims must be receivable digitally to reduce processing time."
The Vague Intent — "We want to improve customer satisfaction." Without a measurable current state and quantified success criteria, this isn't an intent— it's a wish. Better: "Customers currently wait an average of 8 days for claim settlement. Target: under 3 days."
The Solution Intent — "We need a dashboard with real-time overview of all open claims." The solution might be a dashboard — or a proactive notification, a prioritisation algorithm, or an automatic escalation mechanism. Keep the solution space open.
The Mega Intent —"Digitise end-to-end claims processing." That's a Strategic Intent. It needs to be broken into Domain Intents, each describing a standalone, deliverable outcome.
The Contextless Intent — "Claims should be processed faster." Without current state, without numbers, without domain knowledge. Domain knowledge is the fuel of implementation — an intent without it is like GPS without map data.
Why we're publishing this
Every methodology becomes more valuable when more people use it. Spotify didn't patent the Squad Model. Basecamp didn't trademark Shape Up. They defined frameworks, published them, and the industry adopted the terminology.
We believe the same will happen with Intent Engineering. The shift from code-centric to intent-centric delivery is inevitable — because the economics make it inevitable. When AI agents can work autonomously for hours, the value shifts from writing code to understanding problems. The organisations that build this capability first will move at a fundamentally different speed.
The full Intent Engineering Playbook goes deeper: detailed templates, worked examples from insurance claims processing, facilitation guides for Intent Interviews, readiness checklists for handoffs, and scoring rubrics for intent quality. We'll be releasing it as a downloadable resource.
If you're exploring what AI agents mean for your delivery organisation, this playbook is a good place to start. And if you'd rather see it in action than read about it — that's what our Focused Impact Pairs are for.
This is Part 2 of the "New Era of SoftwareEngineering" series.
Part 1: Why We Created the Intent Engineer.
Next: "The Best Intents Come From Watching People Work" — A Conversation With SQUER's First Intent Engineer
