thinking-circle-of-competence

name	thinking-circle-of-competence
description	Use when you're unsure whether you actually know the answer. If you lack the evidence or context to answer reliably, abstain, ask, or fetch it — don't confabulate a confident reply.

Circle of Competence

Overview

The Circle of Competence, articulated by Warren Buffett and Charlie Munger, is about knowing precisely where reliable knowledge ends. For an autonomous agent the operative version is abstention: the failure mode isn't being wrong about a hard problem — it's producing a fluent, confident answer when the grounding for it isn't there. The most damaging output a model can give is a plausible fabrication: an invented API, a hallucinated file path, a made-up statistic, a guessed config value, delivered with the same tone as a verified fact.

Core Principle: Knowing what you can't reliably answer is more valuable than the answer. When the evidence or context to answer correctly is missing, the right move is to abstain, ask, or go fetch it — not to confabulate. "I don't know, let me check" beats a confident guess.

When to Use

• A question demands a specific fact you're not certain of (an exact API signature, a config value, a version behavior, a number)
• You're about to assert something about this codebase/system without having read it
• The request is in an unfamiliar domain and your answer would be reconstructed from vague pattern rather than grounded knowledge
• You notice you're filling a gap with the most plausible-sounding value rather than a checked one
• A confident answer would be expensive to be wrong about

Decision flow:

About to give a specific/high-stakes answer?
  → Is it grounded in something I've read/run/can cite? → yes → answer
                                                        ↘ no → CAN I cheaply fetch/check it? → yes → FETCH, then answer
                                                                                              ↘ no → ABSTAIN or ASK; flag the uncertainty

When NOT to Use

• The answer is grounded and verifiable — you've read the file, run the command, or it's stable common knowledge. Don't perform false humility on things you actually know; needless hedging is its own failure.
• The cost of being wrong is trivial and reversible — a quick reversible attempt with a caveat can beat stalling, as long as you flag it as unverified.
• You can just look it up right now — then the move is fetch, not abstain. Abstention is the fallback when grounding is genuinely unavailable, not an excuse to skip a cheap check.
• Brainstorming / clearly-hypothetical framing — when the user has signalled they want options or speculation, labeled informed guesses are appropriate.

The Three Zones (by grounding, not by ego)

Zone 1: Grounded — answer

The answer is anchored in something checkable

• You read it in the actual code/file/doc this session, or ran it
• It's stable, common knowledge unlikely to be version- or context-specific
• You could cite where the answer comes from

Examples (grounded):
- "This function returns null on miss" — after reading the function
- HTTP 404 means not found — stable, universal
- "The config sets timeout to 30s" — after opening the config
→ Answer directly.

Zone 2: Partial — verify before asserting

Plausible but reconstructed, not confirmed

• You have the general shape but not the specific
• It's version-, environment-, or repo-specific and you haven't checked this one
• You'd be inferring from a pattern, which is usually right but sometimes wrong

Examples (partial):
- "The library probably has a `retry` option" — likely, unchecked
- "This API usually returns ISO timestamps" — depends on the version here
→ Fetch/read to confirm, OR answer with an explicit "I believe X, verify with Y."

Zone 3: Ungrounded — abstain or ask

A confident answer here would be a fabrication

• You'd be inventing a specific value (signature, path, number, flag)
• The domain is unfamiliar and the answer reconstructed from vague pattern
• You can't point to any source for it

Examples (ungrounded):
- Exact signature of an API you haven't seen in this codebase
- A precise statistic with no source
- "What does our internal service X do?" with no access to it
→ Say so, ask, or fetch — do NOT confabulate.

Telling the Zones Apart

The honest test before a specific or high-stakes claim:

Question	Grounded	Partial	Ungrounded
Can I point to where this answer comes from?	✓	sort of	✗
Have I read/run the relevant thing this session?	✓		✗
Is it version-/repo-/config-specific and unconfirmed?		✓	✓
Am I filling a gap with the most plausible-sounding value?		✓	✓

Watch for the confabulation tells:

• An exact name, number, or path arrives with no memory of where it came from
• The answer is suspiciously convenient and complete for something you never looked at
• You're hedging the framing ("typically", "should be") around a claim the user will treat as fact
• "I'm capable in general, so I can answer this specific" — capability is not grounding

What to Do in Each Zone

Grounded: answer directly

✓ Give the answer
✓ Cite the source if it helps the user trust it
✓ Don't hedge a verified fact into mush

Partial: confirm, then answer

→ Cheap to check? FETCH first — read the file, run the command, grep the symbol
→ Can't check right now? Answer with the uncertainty marked:
  "I believe X — confirm against Y before relying on it."
→ Never round a "probably" up to a flat assertion

Ungrounded: abstain, ask, or fetch — never confabulate

Option A: Fetch
- Get the grounding (read the code, search the docs, call the tool), then answer

Option B: Ask
- "I don't have access to X — can you share it / point me to it?"
- A precise question beats a confident guess

Option C: Abstain explicitly
- "I don't know this reliably and can't verify it here."
- State what *would* let you answer

Common Traps

Trap 1: Competence creep

Being grounded in one area doesn't transfer to the adjacent one:

Read service A's code → grounded on service A
Does NOT mean grounded on service B, the infra, or the client
Check the thing you're actually being asked about.

Trap 2: Stale or version-specific recall

General knowledge of a tool ≠ knowledge of this version/config:

"I know how this library usually works" — but the repo pins an old major version
with a different API. Recall is partial here; verify against the installed version.

Trap 3: Fluency misread as grounding

A smooth, complete answer feels authoritative regardless of whether it's checked:

The trap: the more confidently a specific value comes out, the less it gets questioned
The fix: before a specific claim, ask "where did this come from?" — if there's no source, it's ungrounded

Trap 4: Capability-implies-knowledge

Being a strong general reasoner does not mean you know this specific fact:

"I can reason about anything" → still can't know an unread file's contents,
a private API's signature, or a number with no source. Capability is not grounding.

Application Examples

Reporting an API or library detail

Question: "What are the arguments to this client's `query` method?"

Self-assessment:
- Have I read this client's source in the repo? No → Partial/Ungrounded
- Am I about to reconstruct a plausible signature? Yes → confabulation risk

Action: grep/read the actual definition, THEN answer. If unavailable,
        say "I haven't seen this client's source — let me read it" rather than inventing args.

Answering about this specific system

Question: "What does our internal billing service do on a failed charge?"

Self-assessment:
- Do I have access to that service's code/docs? No → Ungrounded
- Can I infer a "typical" behavior? Yes, but it'd be a guess about a specific system

Action: Abstain or ask: "I don't have that service's code here — can you point me to it,
        or should I search the repo?" Do not describe behavior you haven't seen.

Adopting an unfamiliar technology

Question: "Should we use GraphQL here?"

Self-assessment:
- Do I have grounded knowledge of GraphQL's general tradeoffs? Yes → can speak to them
- Do I know THIS system's query patterns and constraints? Only what I've read → check

Action: Give the well-grounded general tradeoffs; for the fit to *this* system,
        verify the actual access patterns before recommending.

Verification Checklist

• Identified which zone the answer falls in (grounded / partial / ungrounded)
• For specific claims: can point to where the answer comes from
• If partial/ungrounded and cheap to check: fetched/read before asserting
• If ungrounded and uncheckable: abstained or asked, did not confabulate
• Marked any unverified claim as unverified, not as fact
• Did not hedge a genuinely-grounded answer into needless mush

Key Questions

• "Where does this specific answer come from — can I cite it?"
• "Have I actually read/run the thing I'm about to describe?"
• "Am I filling this gap with a checked value or the most plausible-sounding one?"
• "Could I cheaply fetch the grounding instead of guessing?"
• "If I'm wrong here, how would anyone find out — and how costly is it?"
• "Is this version-/repo-/config-specific in a way I haven't confirmed?"

Buffett's Reminder

"What counts is not how much they know, but rather how realistically they define what they don't know."

The advantage isn't a bigger circle — it's refusing to answer outside it as if you were inside it. For an agent, the highest-value words are often "I don't know that reliably; let me check" — because a confident fabrication costs far more than an honest gap.