MAIA: Socratic Questioning Instead of Guesswork, or How AI Helps You Put Into Words What You Can't Express Yourself

STEP 1: Log & Distill → record the user's raw input + a short summary
STEP 2: Diagnose → propose visual/technical terms that may lie behind the user's words (internal CoT analysis)
STEP 3: Validate → check the proposal from step 2: APPROVED / NEEDS_REVISION (if revision, go back to step 2)
STEP 4: Respond → ask the user 1-2 multiple-choice questions (≥4 options + "other"), update the state

The loop repeats until every parameter is tagged EXPLICIT or AT_DISCRETION →
the final document is assembled only from confirmed items

Everything happens in one continuous conversation; the roles are different "modes" of the same model, separated by instructions.

Task: You want to commission cover art for your startup podcast from a designer on Fiverr. All you have is a vague feeling: "something cyberpunk-ish, but not quite, and it should look serious, not like some high-schooler made it." You're afraid that if you write exactly that to the designer, you'll get the wrong thing.

Prompt:

You're working with me using the "verification over invention" method: you help 
turn my vague feeling into a concrete brief for a designer.

Roles you play in turn within one conversation:

1. DIAGNOSTICIAN: you analyze what I wrote and propose concrete 
visual terms (style, colors, composition) that MAY lie behind 
my words. For each term, a short explanation in plain 
language, no jargon.

2. VALIDATOR: you check the Diagnostician's proposals. If there's a detail 
I did NOT state directly, it automatically gets the tag 
HYPOTHESIS and must be confirmed by me before it gets into the 
final brief. Nothing should slip into the final version without confirmation.

3. BRIEF WRITER: you assemble the final text only from items 
tagged EXPLICIT (I confirmed it) or AT_DISCRETION (I let the 
designer decide). Items tagged HYPOTHESIS don't make it into the final version.

Track 6 parameters: style, color palette, composition, 
mood/tone, format/size, what can be left to the designer's discretion.
Tag each one: UNTOUCHED / HYPOTHESIS / EXPLICIT / AT_DISCRETION.

For each unverified item, ask me a multiple-choice question: 
at least 4 options + "Other (I'll write it myself)". No more than 2 questions at a time.

Let's start. Here's my idea: "something cyberpunk-ish, but not quite, 
and it should look serious, not like some high-schooler made it".

Result: The model won't hand you a finished brief right away. It will break your phrase down into components ("cyberpunk" → neon colors? a dark palette? a futuristic font? It'll ask), offer 4-5 options for each unclear parameter with an "other" option, and only after you've gone through 2-4 rounds of questions and answers will it assemble the final text brief, where every detail either comes straight from you or is explicitly left to the designer. There won't be any details "added on its own" in the final version.

When you give a model an open task like "write a brief," it can't leave gaps empty; it has to produce coherent text. So it fills in the unknowns with its own default ideas, whatever shows up most often in its training data. This is called "semantic drift": the resulting text sounds convincing but actually describes the model's averaged-out idea, not yours.

At the same time, the model is great at generating relevant choices and sticking to a structure when explicitly asked to: keeping an internal state "counter," tagging items, not moving on to the next step until the previous one is closed.

The method uses this as follows: one "role" of the model proposes, and another checks the proposal against the question "did the user say this, or did I make it up?". It's a built-in fact-checker inside a single conversation that keeps the model's guesses out of the final text without your explicit "yes."

Control knobs: - Number of questions at a time (2) → reduce to 1 for a slow, thoughtful pass; increase for a quick run-through - List of parameters (style, color, composition...) → swap in ones for your task: for a developer spec, features, deadlines, budget, priorities - Finalization condition (all tags EXPLICIT/AT_DISCRETION) → you can relax it, allowing the brief to close with a couple of HYPOTHESES if they're not critical - Role names → replace them with "Art Director," "Editor," "Producer"; specific names strengthen role adherence

You're working with me using the "verification over invention" method: you help 
turn my vague feeling into a concrete document for {task}.

Roles you play in turn within one conversation:

1. DIAGNOSTICIAN: you analyze what I wrote and propose concrete 
terms ({parameter_type}) that MAY lie behind my words. 
For each, a short explanation in plain language.

2. VALIDATOR: you check the Diagnostician's proposals. If there's a detail 
I did NOT state directly, it gets the tag HYPOTHESIS and must 
be confirmed by me before it gets into the final document.

3. WRITER: you assemble the final document only from items 
tagged EXPLICIT (I confirmed it) or AT_DISCRETION (I let the 
contractor decide). Items tagged HYPOTHESIS don't make it into the final version.

Track these parameters: {parameter_list}.
Tag each one: UNTOUCHED / HYPOTHESIS / EXPLICIT / AT_DISCRETION.

For each unverified item, ask a multiple-choice question: 
at least 4 options + "Other". No more than 2 questions at a time.

Let's start. Here's my idea: {your_vague_idea}

Fill in: {task} is what you're putting into words (a brief, a spec, a request), {parameter_type} is the category of details (visual, technical, functional), {parameter_list} is 5-8 concrete items that matter for your task, {your_vague_idea} is whatever you have to start with.

🚀 Quick start: paste this into the chat:

Here's the MAIA template (a method for discovering requirements by verifying hypotheses). 
Adapt it to my task: {your task, e.g. "I need a brief for a 
wedding photographer, but I don't know how to explain what I want"}.
Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask which parameters matter for your specific task and which role each "agent" should play, because the type of task determines what's worth tracking (visual details for design ≠ features for development).

⚠️ Slower than a direct request: the method stretches getting a result over several rounds of questions and answers. If you need a quick result right here and now, this isn't for you.

⚠️ Text only, no images: the researchers deliberately left out image generation, because showing a finished picture too early "overwrites" your vague mental image with its own version. Add visuals too soon and the method loses its point.

⚠️ Tested on a small group: an experiment with 16 participants showed a large and significant effect on "feeling helped to figure things out," but some other metrics (a sense of "ownership" of the result) didn't improve, probably because in transactional commissions people care about the result, not the process.

⚠️ Not for people who already have a clear vision: the method is built for the "I can feel it but can't put it into words" situation. If you already have the finished brief in your head, this process is just extra friction.

MAIA (Multi-Agent Intent Articulation), by Yu-Chao Wang, Yanhong Lu, Yingjie Victor Chen, Tim McGraw, Purdue University. Accepted at IEEE AIxHEART 2026. The system is built on OpenCode Desktop with the MiniMax M2.5 model; the paper's key principle is the rule "Verification over Invention".