Structure Intent

Hiring intent architects

An intent architect turns what an organization wants into structured intent that AI can build from and machines can check. They sit between leadership, domain experts and engineering. They don’t need to be the best programmer in the room. They need to be the clearest thinker about what a system must do, and the most honest about what is actually known.

The role is new, but the people already exist. They are often found among requirements engineers, staff and principal engineers, systems and solution architects, technical product managers, quality and verification leads, and engineers from regulated fields such as finance, healthcare and aerospace.

One role on a team of humans

The intent architect does not decide what a system should do. They structure the intent and bring the right people to each decision. The authority to rule belongs to the intent owner, and each department with a stake represents its own interests: domain experts, engineers, assurance, governance and risk. Agents draft and guess; people judge. A good intent architect makes that collaboration fast and leaves a clear record of who decided what.

The skills to look for

Judgment

  • Asking the right question. They start by clarifying what the system is for and who relies on it, not by proposing a solution.
  • Ranking priorities. They can say what to give up when goals conflict, and defend the choice in plain language.
  • Ruling on intent. Given an existing behavior, they can argue whether it is a promise, an accident or a bug, and they know when the call belongs to someone else.

Precision

  • Stating intent so it can’t be misread. They write short, testable statements, and they notice when a sentence has two reasonable readings.
  • Thinking in examples. They pin down meaning with concrete cases, especially edge cases and rejected inputs.
  • Comfort with formal ideas. They understand preconditions, guarantees, invariants and contracts. They don’t need to be formal-methods experts, but they can read a specification and know what a proof does and doesn’t establish.

Evidence

  • Judging how much assurance is enough. They know the difference between proven, tested, checked at runtime and assumed, and when each is good enough.
  • Honesty about gaps. They record open questions instead of guessing, and they never let a claim run ahead of its evidence.

Working with systems and people

  • Legacy archaeology. They can read old code, tests, logs and tickets to recover what a system really does, and spot where those sources disagree.
  • Facilitation and authority. They can bring stakeholders to a decision, represent each department’s interests fairly, record who decided, and escalate when no one has the authority to rule.
  • Boundary analysis. They can draw a system’s edges: what it covers, which decisions software makes and which people make, and what it trusts without checking. People with security accreditation or safety-case experience often do this well.
  • Fluency with AI. They use AI to draft, extract and check, and they know where its output needs a human ruling.

Learning fast

The skill underneath all the others. Good judgment depends on understanding, and intent architects move between domains constantly. Look for people who can get up to speed on an unfamiliar system or business in days, and who use AI as much to learn as to build.

Interview exercises

  1. Draw a boundary. Describe a process that an AI agent is about to take over, such as approving refunds. Ask the candidate which decisions the agent should make alone, which it should only recommend, and which must stay with a person, and why.
  2. Lift an intent. Give the candidate a short piece of legacy code and its tests. Ask them to write down what it promises, and to flag every behavior they can’t classify as intended, accidental or a bug. Strong candidates produce fewer, sharper clauses and more good questions.
  3. Settle a trade-off. Describe two goals that conflict, such as fraud prevention against checkout speed. Ask them to write the priority rule and explain who should approve it.
  4. Critique the evidence. Show a specification that claims a guarantee is “proven” when it has only been tested on a sample. See whether they catch it and how they would report it.
  5. Explain it to an executive. Ask them to summarize a system’s intent in five sentences for a non-technical leader.

Warning signs

  • They jump to implementation before the intent is clear.
  • They assume an agent can settle questions that belong to a department or an owner.
  • They treat every observed behavior as a requirement, or none of them.
  • They are uncomfortable writing “unknown” or “not yet decided”.
  • They describe assurance in absolute terms: “it’s tested, so it works.”

For the full set of roles, the competencies they rely on and proficiency levels, see the structured intent workforce framework.

Structured intent is a young discipline, and this profile will evolve. See the manifesto for the full picture, and the maturity model for how the role fits an organization’s progress.