← Back to blog

Structured Questions vs Comments — Why It Matters

Why agents need typed answers, not paragraphs of prose.

Every feedback tool in the world defaults to free-text comments. Google Docs, Slack, Jira, GitHub Issues — "write whatever you want."

This works fine for human-to-human collaboration. Humans are great at parsing intent from messy prose.

Agents are not.

The parsing problem

When a reviewer writes:

"I like the overall direction but I'm not sure about the caching strategy. Maybe we should use Redis instead of Memcached? Also, the API naming feels inconsistent. And can we get Sarah's sign-off before proceeding?"

An agent has to figure out:

  • Is this an approval or rejection? (Neither? Both?)
  • What's the actual request? (Change caching, rename APIs, get sign-off — three different things)
  • What's the priority? (Is caching a blocker or a nice-to-have?)
  • Who else needs to weigh in? (Sarah — but for what specifically?)

This is solvable with LLMs, but it's lossy. The agent will interpret, and interpretation introduces error.

Typed answers eliminate ambiguity

Compare the same feedback as structured questions:

{
  "approval": "needs_changes",
  "caching": "Redis",
  "api_naming": "Needs work",
  "additional": "Get Sarah's sign-off on the caching approach"
}

No ambiguity. No parsing. The agent knows:

  • Status: changes requested
  • Caching decision: use Redis
  • API naming: needs revision
  • Action item: get Sarah's input on caching specifically

The four types

Profer supports four question types, each optimized for a different kind of feedback:

  1. Approve — Gate decisions. Yes, no, or needs changes. Drives page status.
  2. Choice — Forced selection from options. No "it depends."
  3. Multi — Checklist. Select all that apply.
  4. Text — Catch-all for when structure isn't possible.

The first three types give agents data they can act on immediately. The fourth is the escape hatch.

Design your questions like forms, not conversations

The best Profer pages have 2-4 questions that cover:

  1. One approve question for the gate decision
  2. One choice or multi for the key design decision
  3. One text for anything else

More than that and reviewers start skipping. Fewer and you're not getting enough signal. It's form design, not conversation design.