Traditional personas are narrative: a name, a photo, a day in the life. Answer engines cannot use narrative. They can use constraints. So the GEA version of a persona is a short list of checkable conditions that describe the buyer's circumstances, and the practical exercise is translating one into the other.
Take each narrative persona and ask: what would have to be true of a company or person for this persona to apply? Headcount band. Budget band. Existing stack. Regulatory regime. Purchase authority. Timeline pressure. Each becomes a line an engine can match against the situation described in a prompt.
Then mark each constraint as hard or soft. Hard constraints disqualify, if the buyer needs on-premise and you are cloud-only, nothing else matters. Soft constraints shade preference. Putting hard constraints in the disqualifier of your hint and soft ones in the scope produces noticeably sharper matching than treating all constraints equally.
Model the negative persona too. Write down the buyer who will ask a prompt your product nearly fits, cost you the citation, and churn if they buy. Naming them explicitly turns a vague worry into a disqualifier line, and it is the fastest quality improvement available to most accounts.
Keep the constraint set small, six to eight lines. Long constraint sets tend to encode internal segmentation rather than buyer reality, and every extra line narrows matching further than intended. If you cannot verify a constraint in your own material, it does not belong in the set at all.
Revisit the sets quarterly against closed-won and closed-lost data. Constraints are hypotheses about who you serve; the CRM is the only place those hypotheses get tested against money. Most teams discover one constraint they were enforcing that the data says does not matter, and one they never wrote down that predicts every good deal.