The agent does the following for every email that arrives in the inbox:

1. read one new email

2. decide whether it looks safe or dangerous, and

3. deliver it, hold it for review, or block it.

Look at step 3 again. The agent does something very important. It acts before it knows everything. It does not know the truth inside an unopened link. It must make a careful decision using incomplete clues. That is why agentic thinking must be probabilistic.

Let us elaborate further based on our understanding so far. Initially our agent has four moving parts:

1. Read new email.

2. Build a new prompt using a program.

3. Ask the LLM model using the Anthropic API - "Is this email safe or dangerous?"

4. If the answer received is safe, then deliver the email or if the answer is dangerous then block it.

Let us denote the above version as V0. It answers, acts and forgets. This model has only two decisions - safe or dangerous. It forgets after the job is done.

Say we have a new email: "Your mailbox closes today if not paid 5000 USD. Sign in now."

This looks like a phishing email. The model returns the answer as "safe" and the V0 agent delivers the email. This is a genuine problem. As a human, we understand that phishing is dangerous and the email needs to be blocked. But V0 has no such understanding.

Therefore, we build something outside V0 that knows the correct answer and compares V0's answer with it.

We need something that can say: "Here is what the agent predicted, and here is what was actually true."

Now we have a new problem - For a new email, we don't know the truth. So, we need a collection of old emails where humans have already established the truth.

That outside mechanism needs a human-labelled test set. Imagine a human safety reviewer. We give that person 100 old emails.

For each email, the reviewer examines the evidence and determines the final verified answer:

Email 1 → Safe

Email 2 → Dangerous

Email 3 → Safe

Email 4 → Dangerous

....

Email 100 → Safe/Dangerous

So we now have a table:

The human-verified answer is the label.

Therefore: Human-labelled test set = a collection of test examples for which humans have already established the correct answer.

During the test, we hide the answer column from the agent. Otherwise the model could copy the answer and the test would prove nothing.

We now connect V0 and the test-set without exposing the answer. That piece is called the evaluation harness. The harness is a scaffolding built around V0 specifically so that mistakes have somewhere to be caught.

What does the evaluation harness do?

There are five steps

1. Hide - Take the email and the corresponding human answer. Hide the answer from V0.

2. Ask - Give only the email to V0. V0 produces the answer - safe or dangerous.

3. Save - save the answer produced by V0 in step 2.

4. Reveal - We reveal what the human said

5. Compare - we compare both the answers in steps 3 and 4 above.

This is the complete evaluation loop.

Hide → Ask → Save → Reveal → Compare

Remember the earlier phishing email ?

The harness now records:

V0 → Safe

Human → Dangerous

Comparison → WRONG

That is how failure becomes visible.

Now we run all the 100 human-labelled emails via V0.

Assume, V0 agrees with human answer on 92 emails and V0 disagrees on 8 emails.

Therefore, Accuracy = 92 / 100 = 0.92 or 92%

92% is thus calculated by the evaluation harness.

Now, to demonstrate why accuracy alone is insufficient, let's construct a deliberately trivial baseline that predicts SAFE for every test email.

In this case, the 8 dangerous emails will be passed as "safe" by V0. The agent collected 92 easy points by repeating the common answer. Yet it failed on every message that the safety system existed to find. Thus the V0 agent cannot detect dangerous emails for which it was originally built. It requires human intervention to inspect the important failures and their consequences.

The share of dangerous messages - 8 out of 100 - is the danger base rate. A base rate answers, “Before inspecting the words of one particular email, how common is this outcome in the population we care about?” Here, the observed danger base rate is 8%.

Because the test has 92 safe rows and only 8 dangerous rows, the two classes are not balanced. This is class imbalance.

We now get back to the inspection of the 8 failures.

We are not interested in the number of wrongs. In this case it is 8. We are more interested in "What kind of wrong"? Does the agent miss attacks, block invoices, misunderstand one language, or fail on hacked real accounts? Once we can name the failure, we can change the prompt, evidence, model, or action rule for a reason. Then we run the same test again and see whether that specific failure improved.

We begin by classifying each result into four categories.

1. True Positive — TP

Agent says: Dangerous. Human says: Dangerous

Correctly caught threat (Correct Alarm).

2. True Negative — TN

Agent says: Safe. Human says: Safe

Correctly delivered safe email.

3. False Positive — FP

Agent says: Dangerous. Human says: Safe

False alarm.

4. False Negative — FN

Agent says: Safe. Human says: Dangerous

Missed threat.

These four counts form the confusion matrix

It is called confusion matrix because we put two things beside each other:

What the agent predicted VS What was actually true. The table shows where they agree and where they get "confused."

It is simply a 2 × 2 count table.

From the confusion matrix we introduce two new concepts precision and recall.

Recall

Start with the human's dangerous emails. Of all the real threats, how many did we catch?

Recall = TP / (TP + FN)

Precision

Start with the agent's dangerous predictions. When the agent says "dangerous", how often is it right?

Precision = TP / (TP + FP)

The useful concepts to memorize:

Recall starts with what was actually dangerous.

Precision starts with what the agent called dangerous.

Let us consider two different errors.

Error 1 - Agent misses a harmless newsletter.

Error 2 - Agent misses a password-stealing email.

Both contribute: 1 wrong answer to accuracy.

But their consequences are completely different.

For example:

• reviewing a safe email → ₹50

• delaying a genuine invoice → ₹500

• delivering a credential-stealing email → potentially ₹10,00,000

So we add another record: What did this mistake cost?

So far We have solved: "How do I measure what happened on past emails?" But we have not solved:

"What should V0 believe about a brand-new email?"

That's because the test set has something a live email doesn't: a known human answer.

For a brand-new email #101:

Email #101 -> V0 ->????

There is no human label available yet.

We therefore cannot run predict → reveal → compare

because there is nothing to reveal. And V0 only knows: Safe / Dangerous

This limitation brings us to chapter 2.

Chapter 2

Chapter 1 was all about - How well did the agent perform when we eventually know every answer?

This was possible because of the human-labelled test set.

For every old email, we had: Email + Human-verified answer

So the evaluation harness could do:

hide answer -> ask agent -> get prediction -> reveal answer -> compare

The truth was already sitting in the answer key.

Now Email#101 arrives. It asks for money by noon.

Now the agent must classify the email as safe or dangerous. But how? This email does not resemble anything from the test set.

The email looks something like this:

From: accounts@example.com
Subject: Invoice account changed

We changed our bank account today. Please use the attached details for the ₹4,80,000 payment due at noon.

It could be any of the four possibilities:

World A

The supplier really changed its bank account.

World B

An attacker copied the supplier's identity.

World C

The real supplier's mailbox was hacked.

World D

It's ordinary spam.

These aren't predictions yet. They are possible explanations of reality.

Actually, the email belongs to one of the above four worlds. There is only one reality.

For this particular email, exactly one complete story is actually true. This is the outcome.

Perhaps: World C = real supplier account hacked

But we have no idea.

Imagine the true story is written on a card and placed inside a sealed envelope. The card says one of:

A → Genuine supplier update B → Copied sender C → Hacked supplier account D → Ordinary spam

The agent cannot open the envelope.

What can it see?

It sees signals:

• sender

• subject

• words

• attachment

• time

• past records

Those are observations. They are clues about reality. They are not reality itself.

Here we introduce three new concepts.

1. Hidden reality - What is actually true. For Message 101: Perhaps the supplier account was hacked.

2. Visible clues - What the agent can inspect.

   For example: sender, subject, attachment, account history.

3. Current belief - What the agent currently thinks those clues support.

   For example: "Hacked account looks fairly plausible."

Why V0 is inadequate?

V0 still does: Email -> Safe or Dangerous.

But after email 101 arrived we now know that the truth could be any one of the four possibilities:

a) genuine supplier update

b) copied sender / phishing

c) hacked account

d) spam

These are possible worlds—possible explanations of what is actually happening.

Now we want the new agent to maintain a record of its uncertainty across these possibilities, instead of immediately collapsing everything into one word - DANGEROUS.

That record is the belief board.

Example:

But why 35%, 35%, 25%, 5%? These numbers are illustrative.

They are not calculated from V0. They are not stored inside V0.

They are an example of what a belief state could look like.

The purpose is to demonstrate the idea: "Instead of saying only Dangerous, suppose the agent explicitly distributes 100 units of belief across the plausible explanations."

So imagine the agent has 100 belief points to distribute.

It might say:

• 35 points support genuine

• 35 support copied sender

• 25 support hacked account

• 5 support spam

The exact numbers could have been different for this illustration—for example, 50/20/25/5. What matters at this stage is that:

1. every plausible world gets some representation

2. the numbers add up to 100%

3. larger numbers mean greater current belief

4. the distribution represents the agent's current uncertainty.

Given the evidence currently available to the new agent, 35% of its current belief is assigned to the "genuine supplier update" possibility. The agent is dealing with uncertainty about which world is actually true.

There is still only one actual reality.

For example, perhaps the real situation is: The supplier's account was hacked.

Then the truth is:

Genuine → FALSE

Copied sender → FALSE

Hacked account → TRUE

Spam → FALSE

The probability describes our uncertainty, not a physical mixture inside the email.

Later, evidence arrives.

For example:

The supplier says, "We never changed our bank account."

Now the agent's belief might shift dramatically toward:

Genuine         3%

Copied sender 12%

Hacked account 83%

Spam             2%

The reality did not change.

What changed was the agent's knowledge about the reality.

The entire board:

Genuine        35%

Copied sender 35%

Hacked account 25%

Spam             5%

is the probability distribution.

The whole arrangement is the distribution.

It represents: How the agent's uncertainty is distributed across the possible stories.

This introduces a new problem. The Finance department asks us: Should I hold back the email. Answer "Yes" or "No". It does not care about percentages and numbers like 35 or 25.

We introduce two new concepts: EVENT and RANDOM VARIABLE to resolve the new deadlock.

The finance team asks us - Does this email require a safety hold?

It means - Temporarily stop the payment/action until the situation is verified.

For us, it means out of the four possibilities which stories should count as yes (to hold back the payment). The answer is Copied Sender and Hacked Account.

These selected group of outcomes is the event.

An event is a selected set of possible outcomes that answers one particular yes/no question.

Event in mathematical form

Our sample space is S= {Genuine, Copied, Hacked, Spam}

Our event is: D= {Copied, Hacked}

So: P(D)=P(Copied)+P(Hacked)

Using our belief board:

P(D)=35%+25%=60%

Therefore: There is currently a 60% belief that this email belongs to the payment-attack event.

Random Variable

Finance team doesn't even want the word "event." Its software wants something executable:

1 = hold

0 = don't hold

So define a rule:

Genuine       → 0

Copied sender → 1

Hacked        → 1

Spam          → 0

We call this rule D. That rule is a: Random variable.

Do not confuse the word random.

The rule is fixed:

Copied → 1

Hacked → 1

Genuine → 0

Spam → 0

What's uncertain or random is which hidden outcome is actually true.

Until we know that outcome, the value of D could be 0 or 1.

Once reality is revealed, D has one definite value.

Why "Bernoulli"?

D can take exactly two values: D ∈ {0,1}

Therefore, it is called a: Bernoulli random variable. The important point is Bernoulli doesn't add new behaviour.

It is simply the standard name for a random variable with two possible values.

So: Random variable -> D -> 0 or 1 -> Bernoulli random variable.

The same belief board can serve different teams

Our distribution remains:

Genuine 35%

Copied sender 35%

Hacked account 25%

Spam 5%

The underlying uncertainty has not changed.

But different teams from the same company have different questions.

The Finance team asks: Should we hold the payment?

We use this mapping which we already discussed above:

Copied → 1

Hacked → 1

Genuine → 0

Spam → 0

Count = Hacked + Copied = 35 % + 25% = 60%

Similar procedures can be applied for the other three teams.

1. IT Security team - Should we quarantine this email?

Mapping used:

Copied → 1

Hacked → 1

Genuine → 0

Spam → 1

Count = Hacked + Spam + Copied = 35 + 25 + 5 = 65%

2. Supplier Risk - Could the real supplier account be compromised?

Mapping used:

Copied → 0

Hacked → 1

Genuine → 0

Spam → 0

Count = Hacked = 25%

3. Reply Assistant - Should we send a normal reply?

Mapping used:

Copied → 0

Hacked → 0

Genuine → 1

Spam → 0

Count = Genuine = 35%

One probability distribution can support many different decisions.

Same belief -> Different Lenses

Why keep "copied sender" and "hacked account" separate?

From the dangerous perspective, we could have combined all emails that are classified as either "Copied sender" or "hacked account".

Each category of the above set of emails on deeper investigation can produce different evidence and responses. For a copied sender, a simple domain check can expose it while for a hacked account the same domain check is not sufficient. To verify a hacker account, we might need additional complexities like:

• known-number phone verification

• account containment

• supplier notification

Two outcomes can have the same broad decision label but require different evidence and different responses.

If we collapse them too early as Dangerous = 60%, we lose the map telling us what kind of danger we might be dealing with.

That map becomes valuable later when we decide what evidence to ask for.

Thus, for the discussion we have had so far for V1 we can summarise as follows:

Step 1: Model returns genuine 35 · copied 35 · hacked 25 · spam 5.

Step 2: Receipt saved: time 9:36 · evidence: email only · model v1.

Step 3: Finance rule: 35 + 25 = 60 → 60 > 20 → hold the payment.

Step 4: IT rule: 35 + 25 + 5 = 65 → quarantine the copy for review.

Step 5: Supplier-risk rule: 25 → below its 40 threshold → no containment call yet.

One model call, one belief, three different decisions. This is what "one belief supports many actions" means — V0 would have needed three separate model calls and might have received three contradictory stories.

Provenance

Suppose the log merely says:

Genuine = 35%

That's not enough.

We should know:

Time: 9:36 am

Evidence: email only

Model: version 1

Belief: 35/35/25/5

Why?

Because if the auditor later asks: "Why did the system believe genuine was 35%?", we can reconstruct what it knew at that moment.

This traceable origin is called Provenance.

Calibration

Suppose the agent repeatedly says: "Genuine = 35%"

What does that number promise?

Across many comparable predictions, roughly:

35 out of 100 should actually turn out genuine.

If instead the agent says 35% a hundred times and 80 turn out genuine, its probabilities aren't trustworthy.

That's called: Calibration

A calibrated 35% prediction should correspond to roughly 35% actual frequency over many comparable cases.

V1 - new Agent

stories ← [genuine, copied-sender, hacked-account, spam]

belief  ← ask_model("Split 100 points of support across
                     these four stories.", email)

save (belief, time, evidence_list)# the provenance receipt

# each team compresses the SAME belief with a different rule
danger_finance  ← belief[copied-sender] + belief[hacked-account]
danger_IT       ← belief[copied-sender] + belief[hacked-account]
                  + belief[spam]
risk_supplier   ← belief[hacked-account]

if danger_finance > 20:  hold(email)        # policy, not belief
else:                    deliver(email)

To design V1 we used the following algorithm:

Step 1: Name the hidden outcome. What complete truth will exist even though the agent cannot see it yet?

Step 2: List plausible worlds. What mutually exclusive stories must the agent keep alive?

Step 3: Build a belief distribution. Given current evidence, how much support belongs to each story?

Step 4: Name the stakeholder's question. Which stories count as "yes" for this decision? That is the event.

Step 5: Map every story to a useful value. This fixed mapping is the random variable.

Step 6: Connect the value to an action policy. Act, ask for evidence, abstain, or escalate.

Step 7: Reveal outcomes later and evaluate. Test both the belief quality and the action consequences.

Chapter 3

The one problem that still exists in the V1 agent from the earlier chapter can be explained as follows:

We saw that for the new email #101 the V1 agent maintained several possible explanations for the email below:

• Genuine supplier update

• Copied sender

• Ordinary Spam

• Hacked supplier account

It attaches its current belief to those possibilities.

So instead of having a binary solution : Safe or dangerous, it can now say -"Several explanations are possible, and here is how much current evidence supports each".

But there is one huge problem. We still have not figured out what to do when new evidence arrives.

Suppose the finance team calls the supplier.

The supplier says: "We did not change our bank account."

That is obviously a "strong clue". But how much should our belief change?

Should we go from 25% suspicious to 77% suspicious or 40% or 99%?
There is no calculated formula to answer that. The agent can write down its belief, but it does not yet know a disciplined way to change that belief when a new clue arrives.

"Strong clue” above does not prove anything conclusive. A genuine email can sometimes produce the same answer: the company may have called an old contact, the change request may have been sent before a paperwork update, or the supplier employee may not know about a legitimate change yet. The phone answer is evidence; it is not the hidden outcome itself.

How should the agent gauge the payment danger after the above phone call ?

The answer is simple: The phone call matters, but the agent V1 needs to know what happens in comparable emails.

The outcome inside message 101 has not changed because of a phone call. One complete possibility from the four possibilities above was already true. What changed is the agent's information, so its belief should change.

We need to answer this question: How often does this particular clue occur when each possible explanation is true?

We need history to answer that and choose the right pile of emails to do so.

Remember the first evaluation set. There were 100 emails - 8 dangerous and 92 safe.

So: 8/100=8%.

That was useful for evaluating V0. But in the earlier chapter we made a very important argument:

That 8% is not automatically the starting probability for Message 101.

This is because we're now asking a different question.

We are no longer asking: "How many ordinary company emails are dangerous?"

We are asking: "Among supplier bank-change requests resembling this one, how often was there a payment-redirection attack?"

Those are different populations.

Imagine three piles of historical emails.

Pile 1 — General evaluation set

There are 100 general emails and 8 attacks.

Rate is 8%

It is useful for evaluating V0.

Pile 2 — Comparable requests during a quiet period

We have 1,000 similar supplier bank-change requests and 10 attacks.

Rate is 10/1000 = 1%

This is a much better starting point for Message 101 during a quiet period.

Pile 3 — Comparable requests during an attack campaign

We have 1,000 similar requests and 200 attacks.

The rate is 200/1000 = 20%

This becomes relevant if security has already confirmed that there is an active attack campaign.

All three piles of email data is from a relevant historical period.

Base rate

From the above three populations, our starting point depends on which pile of emails we select.

For Message 101 during a quiet week:

1,000 comparable requests -> 10 attacks -> 1% starting belief

During a confirmed attack campaign:

1,000 comparable requests -> 200 attacks -> 20% starting belief

Thus for the same type of email with potentially same clue, we have a different environment.

Therefore we have a different starting belief.

This starting frequency is the base rate.

Suppose: P(attack)=1%

That does not mean: "This email has a 1% attack probability forever."

It means: "Before considering the new evidence, comparable historical cases had an attack rate of 1%."

The current email has its own hidden outcome. The historical count simply gives us a starting point.

Build the update physically

Imagine we have 1,000 cards on a table.

Each card represents one comparable supplier bank-change request from the recent quiet period.

Human beings later checked what actually happened.

We know: 10 cards → real payment-redirection attacks

990 cards → not attacks

So before hearing the phone result:

ATTACK       10

NOT ATTACK  990

TOTAL      1000

That's our starting picture.

Put a red sticker on every historical card where the trusted supplier contact said: "We did not authorise this bank change."

Now we discover something interesting.

Among the 10 attack cards: 9 received the red sticker while 1 did not.

So: 9/10=90% of attacks produced this clue. But now look at the other 990 cards.

Among the 990 non-attacks:

20 also received the red sticker while 970 did not.

This is critical. The clue can happen in both worlds.

Now Message 101 gets the red sticker

Message 101 has exactly the clue: "Supplier says: We did not change the bank account."

So which historical cards are relevant now?

Not all 1,000. We filter them by the clue.

1,000 cards -> cards where supplier said "no change" -> 29 cards

Those 29 consist of: 9 attacks and 20 non-attacks.

Now we ask:

"Among cases where this clue happened, how many were attacks?"

Answer: 9/29 = 31%

Thus the counted answer for the whole attack question in a quiet period is 31% or 31 in about 100 attack cases.

Thus we can now answer the Finance department was asking earlier - "Given that we observed this clue (supplier denying that account change was made), how often was there actually an attack?"

Thus from the 1000 cases, we filtered out just the cases where there was evidence of the supplier's denial of making the bank account change. Thus from the large pool of 1000 cases, we created a smaller bucket of cases where the supplier denied making account change. After that we inspect that smaller bucket.

How many of those were actually attacks? How many were not?

That ratio is our updated belief.

Let us dissect this thought process in simpler language.

We have two questions here:

1. Among the attack cases, how often did we see this particular evidence?

2. Among the non-attack cases, how often did we see the same evidence?

An evidence is only useful if it distinguishes an attack from a non-attack.

Suppose we observe: Supplier says: "I did not change the bank account." Now imagine we look at historical cases.

Case A — The clue happens only in attacks

Suppose: 100 attacks → 90 had this clue

1000 non-attacks → 0 had this clue

Then the clue is very powerful. If we see the clue, it's strongly pointing towards an attack.

Evidence strongly separates the two possibilities.

The base rate is the situation before looking at the clue:

So, attacks are:

P(attack) = 100/ (100+1000) = 9.1%

After seeing the clue, we have the base rate P(attack|clue) = 90 / (90 + 0) = 100%

It means attack is certain and no serious base rate trap.

Case B — The clue happens equally often in both

Suppose: 100 attacks → 90 had this clue

1000 non-attacks → 900 had this clue

Base rate before seeing the clue P(attack) = 100 / (100 + 1000) = 9.1 %

After seeing the clue P(attack|clue) = 90 / (90 + 900) = 9.1%

No change in base rate. The clue occurs at the same rate in both groups.

Now the clue is not very useful. Because legitimate cases produce the same clue almost as often. Seeing the clue doesn't help us distinguish:

ATTACK vs NOT ATTACK

We conclude: The posterior remains the base rate because the evidence doesn't distinguish the two groups.

Case C — The clue is actually more common in non-attacks

Suppose: 100 attacks → 20 had this clue

1000 non-attacks → 500 had this clue

The base-rate before the clue = 100 / (100 + 1000) = 9.1%

After the clue, the base rate = P (attack | clue) =20/ (20+500) = 3.85%

The clue actually lowered our belief in an attack.

Thus, seeing the clue might actually make the non-attack explanation more plausible.

So, the important question isn't: "Does this evidence occur in attacks?"

Of course it might.

The important question is: "Does this evidence occur substantially more often in attacks than it occurs in the alternatives?" That's why we need to look at non-attacks too.

The Base-Rate Trap

The trap is easiest to understand if you compare what your brain might do versus what the data says.

In Case C, you might say:

"20% of attacks have this clue, so this clue is associated with attacks."

But that's not enough.

You must ask: "How often does it happen when there is no attack?"

Answer: 50%.

So, the clue actually points more toward non-attack than attack.

We can summarise our analysis in a tabular format.

The base rate is the starting point in all three cases. The evidence then moves us away from, toward, or leaves us at that starting point.

Remember these concepts

1. Base rate = where you start.

2. Evidence = what moves you from that starting point.

3. Base-rate trap = forgetting where you started and letting a seemingly impressive clue dominate your thinking without comparing it against the alternatives.

Technical Terms

We start with a base rate, observe some evidence, and then ask how that evidence should change our belief. Cases A, B and C showed us that the answer depends on how the evidence behaves in the two worlds.

Let's put mathematical names on the things we already understand.

Suppose:

A = an attack

D = the clue/evidence we observed

Before seeing the clue, we have: P(A)

That's our prior — the base rate.

After seeing the clue, what we actually want is: P (A | D)

Read that as: Probability of an attack, given that we observed the clue.

That is our posterior.

Now look at what we were doing in Cases A, B and C.

We were asking: "If there really is an attack, how often do we see this clue?"

Mathematically: P (D | A)

That's the likelihood.

But we also need:

P (D | ~A) which means: "If there is no attack, how often do we see this clue?"

Let us look at Cases A, B and C from a math lens again.

Case A in mathematical language

Starting with the base rate, P(A) = 9.1%

P(D|A) = 90%

P (D | ~A) = 0 %

The clue is therefore extremely strong evidence for an attack.We started with the base rate and after seeing the clue, our belief moves dramatically upward.

The important thing is that the evidence distinguishes the two worlds.

Case B in mathematical language

P(D|A) = 90%

P(D|~A) = 90%

P(A) = 9.1%

The clue doesn't distinguish anything.

Therefore, seeing it shouldn't move our belief.

If the evidence occurs equally often in both worlds, it provides no information for choosing between those worlds.

Case C in mathematical language

P(D|A) = 20%

P(D|~A) = 50%

P(A) = 9.1%

Here the clue actually points away from attack.

Three Observations from the three cases:

1. Evidence more common in ATTACK -> belief in attack increases

2. Evidence equally common -> belief doesn't change

3. Evidence more common in NON-ATTACK -> belief in attack decreases

The three aforementioned rules give us the idea for Bayesian updating.

Bayes' Rule

We can now write the mathematical relationship:

P(A|D) = P(D|A) P(A) / P(D)

Let's understand the logic here.

P(A) = Our starting belief.

That's the base rate.

P(D|A) = How compatible is the evidence with an attack?

P(D) = How commonly could we have observed this evidence overall?

And this last part is where the competing explanation enters.

The clue could have happened because: ATTACK OR NON-ATTACK

So, P(D) = P(D|A) P(A) + P(D|A) P(A)

The above statement tells us: Count every plausible way the evidence could have appeared.

That is exactly what we did earlier.
Case A

We begin with P(A) = 9.1%

P(D|A) = 90% of attacks

P(D|A) = 0.9

but P(D|~A) = 0% of non-attacks

P(D) = P(D|A). P(A) + P(D|A). P(A)

P(D) = 0.9*0.091 + 0*0.909

P(D) = 0.9*0.091

P (A | D) = 0.9*0.091 / (0.9*0.091) = 1

If non-attacks can never produce the clue, then seeing the clue identifies an attack.

P(D∣A)>P(D∣~A)

Evidence favours attack. Belief goes up.

Case B

We have P(A) = 9.1%

P(~A) = 90.9%

P(D|A) = 90%

P(D|~A) = 90%

P(D) = 0.9*0.091 + 0.9*0.909

P(D) = 0.9*(0.091 + 0.909) = 0.9

P(A|D) = 0.9 * 0.091 /0.9 = 0.091

Exactly where we started with P(A).

That's Case B mathematically proving what we already understood intuitively.

P(D|A) =P(D|~A)

Evidence doesn't distinguish.

The belief stays the same.

Case C

We start with P(A) = 9.1%

P(~A) = 90.9%

P(D|A) = 20%

P(D|~A) = 50%

P(D) = P(D|A). P(A) + P(D|A). P(A)

P(D) = 0.2*0.091 + 0.5*0.909

P(A|D) = 0.091 * 0.2

P(A|D) = P(D|A) P(A) / P(D) = 0.2*0.091 / (0.2*0.091 + 0.5*0.909) = 3.85%

So, the clue has actually reduced our belief from 9.1% to 3.85%.

P(D∣A) <P(D∣¬A)

Evidence favours non-attack.

The belief goes down.

The evidence didn't merely "add suspicion." Evidence can increase, leave unchanged, or decrease belief.

Why V2 is better?

V2 tells us that don't just change the belief. Calculate the change from recorded evidence.

For our supplier email:

Relevant historical cases -> starting belief -> new clue arrives -> How often does clue occur under each possible story? -> calculate support -> normalize -> revised belief

The whole calculation is recorded.

So, if V2 says: Attack belief = 31%

It can be verified as follows:

Quiet 90-day period 
1,000 comparable requests

10 attacks 
990 non-attacks

Supplier denial: 
9/10 attacks 
20/990 non-attacks

Support: 
attack = 9
nonattack ≈ 20

Posterior: 9 / 29 = 31%

Same clue, different starting situation.

Quiet period:

1%→31%

Active campaign:

20%→92%

The code didn't change. The clue didn't change.

The starting historical pile changed. V2 records that pile instead of silently choosing a number.

If someone later challenges the starting assumption: "Why did you use this 90-day population?" then we can change the pile because a prior can be stale, too broad, biased, or based on too few examples.

V2 calculates: "How much do we currently believe the attack story?"

It does not decide: "Therefore HOLD the payment."

A 31% belief does not automatically mean HOLD. The action depends on the consequences of being wrong and the cost of delaying the payment.

Chapter 4

In the previous chapter we learnt that when new evidence arrives, update your belief rather than guessing.

But now we encounter a different problem. V2 is dealing with uncertain quantities, and not all uncertainty looks the same.

Consider the questions the inbox system wants to answer:

How many attacks might arrive?

How many attacks might arrive during an hour?

How long until the next attack?

How long does an ordinary invoice email take to process?

These are all questions about uncertainty but notice that they are asking about different kinds of things. That distinction is what this chapter is about.

In the first chapter, the agent V0 asked a simple question - "Is this email safe or dangerous?". The answer was binary but the above question are not binary.

Distribution

A description of how uncertainty is spread across possible values is a distribution.

Suppose the system doesn't know exactly how many attacks will arrive.

It might believe:

0 attacks     → possible

1 attack      → possible

2 attacks     → possible

3 attacks     → possible

...

But those possibilities don't necessarily have equal probability. A probability distribution tells us: Which values are more plausible and which are less plausible?

So instead of saying: "We don't know.", the system can say: "We don't know exactly, but here is how the uncertainty is distributed."

That's the fundamental idea of distribution.

Different types of Distribution

Let us get back to the questions that we are trying to answer.

How many attacks occur?

The answer must be something like:

0

1

2

3

4

...

You cannot have: 2.73 attacks

So this is a count.

But suppose the question is:

How long until the next attack?

Now the answer could be:

0.5 minutes

1.7 minutes

12.4 minutes

37.8 minutes

...

That's a continuous amount of time. Already, the uncertainty has a different shape.

And then there is another distinction.

Suppose we ask:

How many attacks occur during one hour?

That is a count inside a fixed interval whereas

How long until the next attack?

That is measuring the waiting time between events.

These may be related, but they are not the same random quantity.

That is why we need a collection of distributions rather than using probability.

To be more precise we need a mathematical model that matches the question being asked.

In the earlier chapter V2 just did not say, "Attack probability is 31%" but it also helped us to calculate it and audit it.

In this chapter instead of representing uncertainty about one classification belief, we now want to represent uncertainty about quantities and events over time.

So the system may need to reason about: P(X=x)

where X is a random quantity.

The question becomes:

What kind of random quantity is X?

If X is a count, we need one kind of model.

If X is a waiting time, we need another.

If X is a measurement such as processing duration, we may need another.

There are several different probability distributions, each suited to a different kind of uncertainty.

Mathematical Shape

First question: "Does this email need a hold?"

This is the simplest uncertainty.

For one email, there are only two possible outcomes:

0 → No hold

1 → Hold

There is no third possibility.So the uncertainty has the shape: X∈{0,1}

This is called the Bernoulli distribution.

In this case: One trial → one yes/no outcome.

For the inbox agent, this gives the finance team something actionable.

If the current belief that an email needs a hold is: P(hold)=25% and the finance rule is: P(hold) > 20% -> hold

then the agent can actually make the decision.

Without this shape, the agent can only say: "This email looks risky."

There is no precise boundary between risky and hold.

Now change the question slightly.

Instead of asking: "Does this one email need a hold?" ask: "How many of the next 20 emails will need a review?"

Now the answer isn't just 0 or 1.

It can be: 0,1,2,3,4...20

That's a different uncertainty.

Here we are no longer describing one yes/no event. We're counting how many successes occur across 20 opportunities.

That's the Binomial shape.

Thus the distribution is determined by what question we're asking, not by which distribution name we happen to remember.

Poisson

The next question we have is "How many attacks arrive in one hour?"

We have now changed the question again. We are no longer asking: "Out of these 20 requests, how many will need review?"

Instead - "How many attacks will arrive during this one busy hour?"

That answer could be: 0, 1, 2, 3, 4, 5, 6, 7, ...

There isn't a fixed number of requests we're choosing from.

We're watching a stream of attacks arriving over a time interval.

That is the situation for the Poisson distribution.

Exponential

The next question asked was - "How long until the next attack?"

Now the uncertain quantity is time.

It could be:

2 minutes

8 minutes

17 minutes

31 minutes

...

This is the Exponential distribution.

Gaussian

The next question was - "How long does an ordinary invoice review take?"

Here we're measuring a quantity such as review duration. We represent ordinary review times as clustered around a typical value. We do not want to count incidents; we want to estimate a measurement that can vary smoothly: 4.3 minutes, 5.2 minutes, 6.6 minutes.

For a narrow, well-defined kind of routine review, imagine dotting last week's times on a number line. Most dots may sit near 6 minutes. Fewer sit near 3 or 9. A symmetric hill is a useful first picture for measurements clustered around a centre. That hill is called a Gaussian, or Normal, distribution.

Most observations are around the centre; increasingly unusual values occur farther away. That's the Gaussian shape.

The centre is called the expectation, often also called the expected value or mean. In simple language, it is the long-run average the agent expects if it sees many comparable cases. The spread is called variance. It tells us how widely values tend to wander from the centre. It is not a score for good or bad; it is a warning about how predictable capacity is.

This gives the agent a way to recognise something unusually far from the normal cluster.

Uniform

The next question is "Which email gets audited, fairly?"

In this case, we are not trying to model how dangerous an email is.

We only want: **Every eligible delivered email should have an equal chance of being randomly selected for audit.
**So if the audit rate is 1 in 100, every eligible email gets the same chance.

This is the Uniform distribution.

Every eligible email → equal probability.

Why does this matter?

Without it, the audit might repeatedly examine emails that already look interesting. An attacker whose email doesn't look interesting could therefore escape auditing indefinitely. Uniform randomness prevents that bias.

Each question which we discussed in this chapter gives the agent a different operational capability:

Bernoulli → one email: hold or don't hold (hold decision)

Binomial → how many of 20 need review? (staffing)

Poisson → how many attacks arrive in an hour? (alert threshold)

Exponential → how long until the next one? (queue)

Gaussian → how long is a typical review? (anomaly flag)

Uniform → which email gets a fair random audit?

Expectation and variance — average versus spread

Expectation asks:

Where is the middle of the workload likely to be?

Variance asks:

How much can the actual workload move around that middle?

Go back to the 20-email example discussed above.

Suppose each email has a 20% chance of needing a hold.

Then the expected number of holds is 20×0.20=4

So, E[X]=4

The important interpretation is: 4 is the planning centre.

It does not mean: "Tomorrow there will be exactly four holds."

The actual tray might contain 2 holds or 6 holds.

The amount by which the real result moves around that centre is what variance captures.

So, Expectation -> Where should we plan?

Variance -> How much uncertainty should we prepare for?

And that distinction matters operationally.

Expectation helps with ordinary staffing and expected cost.

Variance helps with buffers, alerts, escalation and recognizing when the average is hiding danger.

One very important boundary

Expected = 4 does NOT mean predicted = 4.

It means:

If comparable situations happened many times, 4 is the centre around which the workload tends to sit.

A safe agent therefore doesn't just record the average. It also records the spread, checks its assumptions, and keeps an escalation plan for unusual but important situations.

How does all this actually make the agent better?

Give it one email, give it new evidence, and it could update its belief.

Email
   ↓
prior belief
   +
new evidence
   ↓
Bayesian update
   ↓
posterior belief

But then some team comes up with a new requirement: "Can one reviewer handle tomorrow morning alone?"

This question wants the answer for tomorrow's workload count. Agent V2 has no answer for the same because it lacks the specific mathematical representation for the same.

V3 introduces a registry of uncertain questions

Think of the registry as a collection of properly labelled drawers.

Instead of treating every uncertain question as: probability = some percentage

V3 first asks:

What exactly are we uncertain about? Then it records the appropriate shape.

So the registry might contain:

Question: Does this email need a hold?

Possible values: yes / no

Shape: Bernoulli

Another drawer:

Question: How many attacks arrive in one busy hour?

Possible values: 0, 1, 2, 3, ...

Shape: Poisson

Another drawer:

Question: How long until the next one?

Possible values: positive amount of time

Shape: Exponential

and so on.

V3 doesn't record only the distribution name.

It records question, units, possible values, chosen shape, why that shape was chosen, and the data source.

That's the typed uncertainty registry.

Why are we recording the units and possible values?

Because it catches silly mistakes before they become system decisions.

Suppose someone asks: "How many attacks tomorrow?"

That's a count.

Possible answers are: 0,1,2,3,…

So something like: −3 attacks makes no sense.

Likewise: "How long until the next attack?" is a waiting time.

So, −10 minutes makes no sense.

The question's own type and units help reject an inappropriate probability shape.

The registry also exposes assumptions. Suppose V3 records: Poisson, with a stable hourly attack rate. It's an assumption about reality.

We're effectively saying:

"We believe this arrival process behaves sufficiently like a stable-rate arrival process for this model to be useful."

Now imagine attacks start arriving in coordinated bursts.

Someone can inspect the registry and say:

"The stable-rate assumption isn't holding anymore."

Then the model can be challenged and replaced.

That's much better than burying the assumption somewhere inside the code. This makes V3 auditable.

V2 gave us an evidence receipt. But in V3 the system can record:

What was predicted?
What were the units?
Which shape was used?
Why was it chosen?
What data supported it?
What assumptions were made?
What actually happened later?

Chapter 5

V3 now knows how to represent different uncertainties correctly.

Coming back to our Email #101 example, the suspicious looking email is still unresolved.

There are checks like sender history, link scan, attachment sandbox, domain age, and known-number call which are not pointing to any firm conclusion.

The problem is: Which check should it spend first?

V3 cannot answer that yet. Suppose the current belief board has several competing stories:

Genuine

Copied sender

Hacked mailbox

Spam

The agent could simply perform every available check. But that's wasteful.

Some checks might tell us a lot. Some might tell us very little.

So instead of asking: “Which check sounds useful?”

Chapter 5 wants the agent to ask:

"Before I actually perform this check, how much do I expect its possible answers to reduce my uncertainty?"

In Chapter 3, the agent waited for evidence and then updated:

Evidence arrives -> Bayesian update -> new belief

Chapter 5 wants the agent to reason before obtaining the evidence:

current belief -> possible check -> imagine each answer it could return ->

-> for each answer: "what would my belief become?" -> how much uncertainty would this check remove on average? -> compare with other checks -> choose the most useful one

It reuses the Bayesian update engine from Chapter 3. The agent essentially asks: "If I ran the link scan and it returned answer A, what would my belief become?"

Then: "What if it returned answer B?"

Then it does the same for sender history, domain age, the known-number call, and so forth.

Only after mentally simulating the possible outcomes does it decide which check is worth performing.

We want: The check whose answers are expected to separate the competing invoice stories the most.

The agent's current belief is:

But Finance team cannot sit there forever looking at: 45%, 30%, 20%, 5%.

The agent needs more evidence.

And it has several permitted ways of getting it:

• inspect sender history

• safely inspect the link

• check domain age

• sandbox the attachment

• call the supplier using the trusted phone number already stored in the vendor record.

Which one should the agent do first? This chapter is trying to solve this problem.

Why not just perform every check?

Because checks aren't free. They consume time and resources.

Some may require a human. Some may not even be relevant to this particular email. So, **"Run everything" isn't an intelligent evidence strategy.**But neither is "Run the link scan because that sounds useful."

The agent needs a principled way of choosing.

Think about what a useful check should accomplish

The agent currently has four competing explanations. A useful check should help it separate those explanations. Consider the link scan.

Suppose it returns: LOOK-ALIKE DOMAIN

That strongly supports the copied-fake-sender explanation. Because historical verified cases tell us that look-alike domains occur very frequently in copied-sender attacks and rarely in the other explanations.

P(copied)=45%

P(hacked)=30%

P(genuine)=20%

P(spam)=5%

Now the scanner actually returns: LOOK-ALIKE DOMAIN

From the historical ledger, we have:

P(look-alike | copied)=89%

P(look-alike | hacked)=3%

P(look-alike | genuine)=5%

P(look-alike | spam)=0%

Calculate support for each story

For copied sender: 0.45×0.89=0.4005

For hacked mailbox: 0.30×0.03=0.009

For genuine: 0.20×0.05=0.010

For spam: 0.05×0=0

So our unnormalised support is:

Copied       0.4005

Hacked      0.009

Genuine     0.010

Spam         0

----------------

Total          0.4195

Now normalize.

For copied sender: P(copied | look-alike)=0.4005 / 0.4195≈0.955

Therefore: P(copied | look-alike)≈95.5%

Thus, After that result, the belief becomes approximately: 95% copied sender

Suddenly:

BEFORE

Copied     45%
Hacked     30%
Genuine    20%
Spam        5%

          ↓ link scan
          ↓ LOOK-ALIKE

AFTER

Copied    ~95%
others     ~5%

The agent has learned something important.

But suppose the link is normal

Now something different happens. The copied-sender explanation becomes much less plausible.

But we cannot say the email is safe.
Because the second explanation was: The attack came from the supplier's actual hacked mailbox.

In that situation, of course the domain looks genuine.

So after a normal-domain result, the agent might end up roughly around:

Copied      9%

Hacked     50%

Genuine    33%

Spam        9%

BEFORE

Copied     45%
Hacked     30%
Genuine    20%
Spam        5%

          ↓ link scan
          ↓ NORMAL

AFTER

Copied    ~9%
Hacked    50%
Genuine   33%
Spam      9%

How did we derive that?

We already know the historical probabilities for look-alike:

P(L | Copied)=89%

P(L | Hacked)=3%

P(L | Genuine)=5%

P(L|Spam)=0%

So if the scanner has only these two outcomes—look-alike or normal—the probabilities of a normal result are simply the complements:

P(N | Copied)=1−0.89=0.11

P(N | Hacked)=1−0.03=0.97

P(N | Genuine)=1−0.05=0.95

P(N | Spam)=1−0=1.00

The starting beliefs are still:

Copied=45%

Hacked=30%

Genuine=20%

Spam=5%

Now: Prior × Likelihood

For copied sender: 0.45×0.11=0.0495

For hacked mailbox: 0.30×0.97=0.291

For genuine: 0.20×0.95=0.190

For spam: 0.05×1=0.050

                 Prior × likelihood

Copied      →    0.0495
Hacked      →    0.2910
Genuine     →    0.1900
Spam        →    0.0500
                  ------
Total            0.5805

Now we normalize, exactly as before.

For copied: 0.0495/0.5805= 8.5%

For hacked: 0.291/0.5805 =50.1%

For genuine: 0.190/0.5805=32.7%

For spam:0.050/0.5805 =8.6%

So after receiving NORMAL DOMAIN, the updated belief is approximately:

Copied=9%,Hacked=50%,Genuine=33%,Spam=9%

And this makes intuitive sense.

A normal domain is unlikely if someone copied/faked the sender—only 11% of those historical cases had a normal domain. So copied sender collapses from 45% → 9%.

But a normal domain is extremely likely if the real supplier mailbox was hacked—97% of those cases had a normal domain. Therefore hacked mailbox rises from 30% → 50%.

Now we've seen that, Copied sender is much less likely.

But we're still uncertain between: hacked real mailbox and genuine request. This is exactly why no single check necessarily settles everything.

But there is a complication

The agent cannot choose what answer the tool gives.

For the link scan:

                 LINK SCAN
                    │
          ┌─────────┴─────────┐
          ↓                   ↓
      LOOK-ALIKE            NORMAL
          ↓                   ↓
   almost settles       still uncertain
   copied-sender        hacked vs genuine

So we cannot judge the link scan merely by saying: "Look-alike would be extremely useful." Because perhaps the scanner returns normal. Therefore, the real question is: Considering ALL the answers this check could produce; how useful do we expect the check to be?

First, we need to measure uncertainty

Our current belief is: 45%,30%,20%,5%

We need a number representing: **How uncertain is this belief distribution?**That number is called entropy.

Entropy = amount of uncertainty remaining.

If the belief were, Copied sender 100% and Everything else 0% there's essentially nothing left to figure out.

Entropy = 0

But:

Copied     25%
Hacked     25%
Genuine    25%
Spam       25%

is highly uncertain. Every explanation is equally plausible. Entropy is much higher. Our actual: 45/30/20/5 lies somewhere between those extremes.

Why do we need entropy at all?

The agent has beliefs: 45%,30%,20%,5%

The agent is now uncertain. This uncertainty does not answer questions that need some measurable numbers. So, entropy comes into picture.

Probability distribution -> one number measuring uncertainty

Information theory starts from a very intuitive requirement: Rare events should give us more information than expected events.

Suppose something has probability, P=50%

Seeing it gives some information.

But if something had probability, P=1% and it actually happened, you've learned much more.

So, we need a mathematical function where:

high probability → little surprise/information

low probability → lots of surprise/information

The logarithm gives us exactly that behavior.

I(x) = -log to the base2 (P(x))

P = 1/2 => I = 1 bit

P = 1/4 => I = 2 bits

P = 1/8 => I = 3 bits

If something becomes twice as unlikely, it contributes one additional bit of information.

That's why logs fit naturally into our problem scope.

We don't know which of our four invoice explanations will eventually turn out to be true.

So information theory asks:

On average, how much information is still required to resolve which explanation is true?

That produces:

H(X) = - Sigma(P(X) * log to the base2 P(X))

That's entropy.

We compare entropy before and after evidence. This gives information gain.

We are not just asking this question: What is the probability that the invoice is fraudulent?

We want to know: "How much information would I gain by performing this check?"

Probability represents what the agent believes; entropy measures how unresolved those beliefs are; information gain measures how much a new check is expected to resolve them.

Applying, the entropy formula to our link scan beliefs we have,

H(X)=− [p1​ * log2​p1​+p2 * ​log2​p2​+p3* ​log2​p3​+p4 * ​log2​p4​]

P(Copied sender) = P(C) = 0.45

If copied sender turns out to be the truth, how surprising was that outcome?

Information theory measures surprise as:

I(X) = - log2(P(X))

So, for copied sender -log2(0.45) = 1.15

This is 1.15 bits of surprise/information

For Spam P(S) = 0.05,

The surprise is -log2(0.05) = 4.32.

This is much larger in comparison to the copied sender.

But we have not yet concluded which explanation turns out to be true.

Copied sender would give us 1.15 bits of information if copied sender occurs.

But it currently has only a 45% chance.

So we weight its information by its probability: 0.45×1.15

Add the final column -> 0.52 + 0.52 + 0.46 + 0.22 = 1.72

Therefore, H(X) = 1.7 bits

What remains is mainly putting information gain into the agent's actual decision loop:

1. Compare candidate checks:

The agent estimates information gain for each permitted check—link scan, sender history, known-number call, etc.—and ranks them by how much uncertainty they are expected to remove.

2.Run the chosen check, then re-plan.

This is important.

The agent does not calculate a fixed sequence such as:

link scan → sender history → phone call.

It chooses one check, receives the result, performs the Bayesian update, and then recalculates what evidence would now be most useful.

3.Information gain is not the same as utility.

A check can be highly informative but expensive, slow, privacy-sensitive, unavailable, or irrelevant to the actual decision.

So, this chapter establishes “which check teaches me most?” but does not completely solve “which action is worth taking?”

That distinction leads forward.

4. V4 / Evidence Planner.

This is the engineering payoff. The agent has progressed from:

V2: update belief when evidence arrives

to

V4: Actively decide to seek which evidence next

Choosing the next check

The agent has several checks available. For each one, it can estimate:

"If I perform this check, how much uncertainty do I expect it to remove?"

That's information gain.

So instead of choosing a tool because it sounds useful, V4 can rank candidate checks using expected information gain.

For Email 101, the link scan was more informative than sender history at that particular moment.

The result arrives — and the ranking can change

Suppose the link scan returns:

NORMAL DOMAIN

We already calculated what Bayes does with this.

Approximately:

BEFORE

Copied sender     45%
Hacked mailbox    30%
Genuine           20%
Spam               5%

        ↓ NORMAL DOMAIN

AFTER

Copied sender      9%
Hacked mailbox    50%
Genuine           33%
Spam               9%

Now the problem facing the agent is different. Originally, copied sender was the leading explanation.

After the normal-domain result, the important unresolved question has become:

Is this the real supplier whose mailbox was hacked, or is this actually a genuine request?

Therefore the agent should not blindly execute the check that was originally ranked second.

It calculates again:

Given what I believe now, which available check would reduce the remaining uncertainty most?

At this stage, the known-number call can become much more valuable.

This is an important agentic behaviour.

The plan is adaptive.

So V4 works as a loop.

Current belief
      ↓
Which check would teach me most NOW?
      ↓
Choose check
      ↓
Get evidence
      ↓
Bayesian update
      ↓
New belief
      ↓
Which check would teach me most NOW?
      ↓
Choose again
      ↓
...

So every new piece of evidence can change both:

1. what the agent believes;

2. what the agent wants to investigate next.

That is the Evidence Planner introduced in V4.

But don't make information gain too powerful

There is one final boundary this chapter wants us to preserve. Suppose Check A has the highest information gain.

Does that automatically mean: Run Check A.

No.

Information gain answers only: Which check is expected to reduce my uncertainty the most?

It doesn't automatically consider everything we care about. A check may be highly informative but:

• expensive

• slow

• unavailable

• restricted by policy

• privacy-sensitive

• or unlikely to change what we ultimately do

V3 → V4

This is the cleanest way to remember what changed.

V3

The agent understands the shape of uncertainty.

It knows that different questions require different probability models.

But when investigating Message 101, it still doesn't know:

Which evidence should I seek next?

V4

Adds the Evidence Planner.

The agent can now:

1. Maintain competing beliefs
              ↓
2. Consider available checks
              ↓
3. Imagine each check's possible results
              ↓
4. Use Bayes to calculate what
   beliefs would follow each result
              ↓
5. Measure expected reduction
   in uncertainty
              ↓
6. Rank the checks
              ↓
7. Perform one
              ↓
8. Observe actual evidence
              ↓
9. Bayesian update
              ↓
10. RE-PLAN

Entropy measures how uncertain the agent currently is; information gain measures how much a check is expected to reduce that uncertainty.

V4 uses that information gain to choose evidence adaptively—check, observe, update with Bayes, then decide what evidence is worth seeking next.

Chapter 6

After the investigation, suppose the agent's belief is:

P(attack)=31%

Therefore: P(not attack)=69%

Now here's the question: What should the agent actually do?

A naive approach would be: "69% says not attack. That's the more likely outcome. Deliver."

And Chapter 6 says:

That's the wrong way to choose an action.

Why?

Because probability tells us what is likely. It does not tell us what a mistake will cost.

Look at the consequences

If we deliver an attack by mistake:

cost = ₹10,00,000

If we hold a genuine invoice unnecessarily:

cost = ₹500

Human review: ₹250

Now reconsider the 31% attack belief.

Option 1 — Deliver

If we deliver an attack by mistake:

There's a 31% chance we're delivering an attack.

If that happens, the loss is ₹10,00,000.

So, 0.31 * ₹10,00,000 = ₹3,10,000 ​

That's the expected loss of delivering.

Option 2 — Hold and escalate

There's a 69% chance the invoice is actually genuine.

If genuine, holding it unnecessarily costs ₹500.

So:

0.69×₹500=₹345

Then add the human-review cost: ₹345+₹250 = ₹595

So compare

DELIVER
Expected loss ≈ ₹3,10,000

HOLD + HUMAN REVIEW
Expected loss ≈ ₹595

Now the decision becomes obvious: HOLD

The agent believes: 69% not attack. Yet it chooses HOLD.

That is not a contradiction.

The most likely story is probably not an attack. But the best action is hold.

Because the consequences are radically asymmetric.

Wrongly deliver attack -> ₹10,00,000 damage

Wrongly hold genuine invoice -> ₹500 damage

The most probable outcome is not necessarily the outcome you should act as though is true.

Instead, choose the action with the lowest expected damage​.

This finally explains the threshold

Earlier we encountered rules such as: If attack belief exceeds some percentage, HOLD.

Where should that percentage come from?

Not from - "35% feels risky."

Instead, the threshold is approximately the point where,

Expected loss of delivering = Expected loss of holding

Below that point, delivering may be cheaper. Above that point, holding may be cheaper.

So, a threshold is really:

The belief level where the preferred action changes because the expected consequences cross over. And if the costs change, the threshold should change too. That is a very important connection to our earlier chapters.

This is the conceptual heart of Chapter 6.

Probability tells us what may be true​.

Expected loss helps decide what to do​

and

Value of information tells us whether another investigation is worth buying​

The remaining part of the chapter turns this into V5's explicit Act / Ask / Hold / Escalate policy, including permissions, deadlines and human-review capacity.

The agent should not have only two crude choices like: deliver or block.

It needs four honest moves:

Act when the expected harm is acceptably low and policy allows the action. Ask when another permitted check is expected to improve the decision enough to justify its cost and delay.

Abstain / hold when the agent cannot safely decide automatically.

Escalate when a qualified person or approved workflow is required.

This is important because abstaining is not failure.

For Message 101, saying: "I am not releasing this payment automatically." can be the correct system behavior.

The policy must then say what happens next: how long the hold lasts, who gets notified, and what happens if nobody responds. V5 behaves almost like a small state machine.

It begins with everything it already knows:

• current belief

• payment amount

• available evidence checks

• permissions

• deadline

• human-review availability

Then it passes through a sequence of gates.

First: Is there a hard business rule requiring verification?

If yes, the agent holds. It is not allowed to say:

"My probability is low enough, so I'll bypass the rule."

Hard policy rules sit above the probabilistic calculation.

Then it asks: Is there another permitted check whose expected decision benefit exceeds its full cost and that can finish before the deadline?

If yes: ASK -> obtain evidence -> Bayesian update -> recalculate

If not, stop asking.

Then it asks: Is an automatic action permitted and sufficiently safe under the policy?

If yes: ACT.

Otherwise, ESCALATE to an eligible person.

And if no eligible person is available - ABSTAIN / HOLD.

So, uncertainty never leads to an undefined state.

Why "escalate to a human" is not enough

It's tempting to design:

if uncertain: send_to_human()

But humans are also a constrained resource.

A review queue has limited capacity, delay, accuracy limits, and authority boundaries.

So a real escalation policy needs to say:

Who receives the case? What happens to the payment while we wait? What deadline applies? What if the queue is full? Which decisions are never allowed to happen automatically?

Now V5 combines everything

Conceptually

for each possible action:
    calculate expected loss

choose lowest-loss permitted action

then ask:
    could one more check improve that decision enough
    to justify its cost?

if YES:
    run check
    update belief
    repeat

if NO:
    take the best permitted action

Message 101 closes the loop

After the phone call: P(attack)=31%

Expected loss of delivering: 0.31×₹10,00,000=₹3,10,000

Expected loss of holding and human review: 0.69×₹500+₹250≈₹595

So V5 chooses: Hold and escalate.

So V5 adds

Belief
   ↓
Possible actions
   ↓
Expected loss
   ↓
Best permitted action
   ↓
Would more evidence improve the decision enough?
   ↓
YES → ask
NO  → act / hold / escalate

And now the whole journey closes

The agent began as:

Email
 ↓
SAFE / DANGEROUS

It ends as something much richer:

Email
 ↓
Possible hidden explanations
 ↓
Belief distribution
 ↓
New evidence
 ↓
Bayesian update
 ↓
Correct uncertainty model
 ↓
Choose useful evidence
 ↓
Entropy / information gain
 ↓
Evaluate consequences
 ↓
Expected loss
 ↓
Is more evidence worth its cost?
 ↓
ACT / ASK / HOLD / ESCALATE
 ↓
Record receipt
 ↓
Later compare with confirmed outcome

A good agent does not merely try to be certain. It decides when more certainty is worth buying, when uncertainty is acceptable, and when the consequences demand that it stop and hand control to a safer path.