agentbull/ankole/resolve-before-asking

Resolve before asking

Never ask "who is X?" when memory already answers. The memory answers before the human is bothered — that is the product promise. Asking the user about an entity whose page carries a role line, a timeline, and meeting history spends their attention on a question the system can answer itself.

When this fires

• A reply draft contains "who is [name]?" or an equivalent question.
• A draft asks about someone's role, relationship, or identity.
• You are about to present an entity as unknown or unidentified.
• You are composing a list of people and leaving any as "unknown".

The lookup chain

Run in order. Stop at the first clear answer.

1. This conversation. The thread, its participants, and the channel often

name the person already.

1. `entity`. Pass the name as name. The result contains entity

with its page ID, outline, metadata, current facts, takes, timeline, backlinks, and children; an ambiguous name returns candidates instead. A card that establishes the identity resolves the entity.

1. `recall`, narrowed with `entity`. Facts and takes come back first.

Three timeline entries that repeat one role description settle the question.

1. Read the full Pod page. Call pod_get_page with the returned page

UUID as id and level: "L2". Read its body and visible children; entity supplies current claims, timeline, and relationships. In a Background Agent Job, use ankole-pod pages.read with that page ID to read the source text. Do this before concluding that memory does not know.

1. `synthesize`. Only when the answer needs threads connected across many

pages; it is expensive. A clear synthesis answer ends the chain.

1. External search. Web or channel tools, seeded with the hints steps 1–5

accumulated. remember what you confirm, with its provenance, so the next lookup does not repeat the work.

1. Ask — with a hypothesis. Only after all previous steps return nothing

conclusive.

Confidence

• High — do not ask. The entity card or synthesis gives a clear answer,

or repeated timeline entries carry one consistent role.

• Low — ask, leading with your best guess. Signals are contradictory or

very sparse. Open with the hypothesis, and state the contradiction when there is one.

There is no third state: either memory answered, or you finish the chain and ask with a hypothesis.

How to escalate

State what you searched, state what you found — partial signals included — and ask one specific, confirmable question:

Is Jane the operations lead at Acme? I find recurring invoice threads from

@acme.example and two meetings alongside the Acme team, but nothing names

her role directly.

Never a bare "who is Jane?".

Email-domain shortcut

A sender's domain seeds the hypothesis; it is never proof.

Anti-patterns

• "Who is X?" with no prior lookup.
• Asking about a relationship when the person's page holds a long timeline.
• Presenting a list of unknowns without running the chain on each name.
• Treating one recall hit as chain-complete: read the page before you

conclude "not in memory".

• Escalating with false confidence: a partial signal is a hypothesis, not a

resolution.

The standard

Would the user look at this entity's memory — the timeline, the role facts, the email domain that names an employer — and find it reasonable that you asked? If not, the chain was not run. Run it.