Help us build the next chapter.

Demo A — Sales pipeline hygiene: the orchestrator overrules its own subagent

Run date: Friday, 31 July 2026 · Elapsed: 11:11 → 17:48 ET · Output: a written audit file, three email drafts, two CRM task closures, one task rescheduled

Every weekday CyberSecureRIA runs an agentic sweep of its CRM pipeline. One

orchestrator reads the day's due task queue, dispatches an enrichment subagent

per contact, hands writes to a separate agent that is the only one permitted to

touch the CRM, and files a dated audit record. This is the record from

31 July 2026, redacted.

Names, firms, domains and contact details have been replaced with role labels.

Ticket numbers, record IDs, dates and timestamps are unchanged — on their own

they identify nobody.

What to look at. Not the eight tasks that were worked. Look at the two

places where the orchestrator re-ran a subagent's check, kept the answer, and

threw out the argument that produced it.

---

The queue

Queue fetched with due_date=lte:2026-08-01: **8 open tasks, all due

2026-07-31, all already assigned.**

>

Reassignment buckets checked and all empty — no writes needed:

duplicate-user bucket → count 0; shock-and-awe bucket → count 0; list-scrub

bucket → count 0.

Annotation. "Verified rather than assumed" is doing real work in that

second block. Three routing rules exist; the run confirmed each returned zero

rather than reporting "no reassignments needed" because none came to mind.

A rule that was never evaluated and a rule that returned empty look identical

in a summary.

---

The centerpiece: an unsigned agreement

An enrichment subagent was asked whether a prospect had signed the engagement

agreement sent to him. It returned two claims:

1. He has not signed.

2. He has not even opened the document since it was resent on 29 July —

supported by two fields on the e-signature envelope.

The orchestrator did not accept the report. It re-queried the e-signature

platform itself, read-only, creating and sending nothing:

getEnvelope(...) → status: "sent" — not completed, not declined, not

voided.

>

listRecipients → **the prospect: status: "sent", completedCount: "0",

no deliveredDateTime.** The CEO: status: "completed",

signedDateTime: 2026-07-16T14:50:33Z (countersigned day one).

>

sentDateTime: 2026-07-29T21:10:56Z confirms the resend landed.

Correction 1 — conclusion upheld, reasoning rejected

CORRECTION 1 to the subagent report: it claimed lastModifiedDateTime is

identical to sentDateTime and that any view would have advanced it. False —

lastModifiedDateTime is 2026-07-16T14:50:07Z (the original send).

statusChangedDateTime is the field matching the resend. The not-signed

conclusion survives via the recipient row, which is direct evidence; **the

specific field argument was wrong.**

Annotation. The subagent's answer was right. Its reason was wrong, and it

was wrong in the most durable way — a plausible claim about a timestamp field

that nobody downstream would ever re-open, sitting inside a conclusion that

happened to be correct.

>

The orchestrator separated the two. It kept the finding because the recipient

row states the signing status directly, and it discarded the timestamp

argument because that argument was checkable and did not check out. A run that

only graded conclusions would have marked this one green and moved on.

Correction 2 — a claim downgraded from strong to weak

**CORRECTION 2 — the "hasn't viewed since the resend" claim is weaker than

presented.** The subagent leaned on the absent deliveredDateTime. But this

recipient has no deliveredDateTime at all, including before 7/24, when

he demonstrably DID open the document — he quoted the incorporation-by-

reference clause verbatim and correctly noted the envelope carried only one

exhibit. So that field does not track this recipient's views and cannot

distinguish "never opened" from "opened, not stamped."

>

The email-side evidence (no "viewed" notification from the e-signature vendor

since 7/24, **apparatus controlled against six other clients' full envelope

lifecycles in the same window**) is the real support — good, but softer than

claimed.

Annotation — this is the paragraph to read twice.

>

Three separate moves happen here, and each is a thing an unsupervised agent

normally skips.

>

It found the counter-example. The field was empty, and the subagent read

empty as "did not happen." The orchestrator went looking for a moment when the

thing had definitely happened and checked the field then. It found one: a week

earlier the prospect had quoted the contract back, clause by clause, which is

only possible if he read it. The field was empty then too. An empty field that

is empty when the event occurred is not evidence about the event.

>

It controlled the apparatus. The replacement evidence is the absence of

vendor notification emails. An absence is worthless if the mailbox search is

broken, so the same query was run against six other clients' envelopes in the

same date window, where it returned full send / view / sign lifecycles. The

search works. The absence means something.

>

It downgraded rather than deleted. The conclusion stayed. Its confidence

did not. The audit file records the claim as "good, but softer than claimed"

— which is what the human reading it on Monday needs to know before repeating

it to a prospect.

Operationally unchanged: not signed, a nudge is warranted, the ball has been

his seven days. The run also recorded a documentation gap — the newest CRM note

on the contact is dated 6/30, and nothing in the CRM records the 7/16 send, the

7/24 contract exchange, or the 7/29 resend.

---

Four more corrections in the same run

The self-correction above was not a one-off. The same audit file records five

other places where something already written down turned out to be wrong.

A fabricated price, labelled as verified. An opportunity's next-action notes

asserted a per-user price and annotated itself *"VERIFIED CORRECT … No

correction needed."* The figure did not correspond to any quote on record. It

was overwritten with the real basis — two line items that sum to the actual

monthly figure.

Annotation. The dangerous part is the annotation, not the number. A wrong

number invites a second look. A wrong number stamped "verified" ends the

conversation.

A metric that counted the same email several times. A prior run reported

"13 outbound / 2 inbound" for one prospect. That was a raw row count, and the

mail index stores a separate row per folder copy, plus self-forwards. The real

record: 4 unique inbound, 5 substantive outbound.

A correction that never happened. A contact's company field was annotated

*"Corrected 2026-07-30."* It was still empty. The run established why: the CRM's

update call has no parameter for that field at all — it takes a company ID and

derives the name from a linked company record, and no such company record

exists. An unrecognized parameter collapses into a generic *"No update fields

provided"* error, which reads exactly like a silent drop. Filed as a tracked

issue rather than left in a comment, and the false annotation was superseded in

place rather than deleted.

Two copies of one email, labelled backwards. A prospect's reply existed

twice in the index — once in the CEO's mailbox, once in a colleague's. The

enrichment agent had them the wrong way round. Replying to the copy it named

would have created the draft in the wrong person's mailbox, where the CEO would

never have seen it and the prospect would never have received it. The run

identified the owning mailbox from the message-ID prefix before drafting.

Two research subagents disagreed; the orchestrator went to the vendor. One

said a mobile-device feature required a specific paid tier; another said it was

included a tier lower. This determined whether a prospect would need to spend

roughly $— a year. Rather than picking the more confident agent, the

orchestrator fetched the vendor's own feature-comparison page and read it:

the feature is listed under the higher tier, and the lower editions are absent

from that tier's edition list. The cheaper answer was wrong, and the cost line

went into the client email.

And one subagent corrected itself mid-task. A researcher's first pass read a

vendor pricing page through a summarizer that attributed an enterprise mobility

feature to every plan tier. It re-derived the answer from the raw page and each

article's availability box. Its own note on the matter: uncorrected, the

recommendation would have told the prospect they get that capability on a

mid-tier plan, which is false.

---

What the run refused to conclude

A day's audit is judged as much by what it declined to assert.

"Did he make the call?" — escalated, not inferred. A 9:00 a.m. call slot had

elapsed. The run checked for every trace: zero CRM notes, task modification date

untouched, no support ticket, no inbound email, no new calendar event. It then

stated the limit of its own negative:

Each of those records a *side effect* of a call. An unlogged mobile call

produces none. Cannot distinguish "didn't dial" from "dialed, didn't log."

ASK JONATHAN — do not infer.

That instruction is not caution for its own sake. CyberSecureRIA audited this

class of finding and measured it: **91% of "you missed a follow-up" claims were

false — 40 of 44.** The founder follows up from his own tools, so the CRM goes

stale while the work gets done. The prior is written into the operating

instructions, and the run applied it.

The email zeros were controlled. Before trusting any "no email found"

result, the run searched a known-busy sender and got 75,319 matches, newest that

day. The zeros come from a live index, not a broken query.

A calendar was discarded as evidence. A colleague's calendar returned zero

matching events. The run checked whether it returned zero for a two-month

control window as well. It did — so the calendar is unindexed, not empty, and it

was excluded from the reasoning entirely.

A visibility gap was recorded as a gap. Whether that colleague also

telephoned the prospect could not be established either way; her calls leave no

trace in any reachable system. The audit says so, in those terms, rather than

recording an absence of evidence as evidence of absence.

Two contacts were confirmed not to exist. Two email addresses attributed to

a prospect firm produced zero artifacts. Both domain sweeps were confirmed

untruncated — 6 of 6 and 2 of 2 — before the conclusion was drawn.

---

What the queue would never have found

Two of the day's most consequential items were not in the task list at all.

• A prospect had replied two days earlier with a direct question and was

waiting. His CRM task offered two branches — "replied ready" and "no reply by

Friday" — and neither fit. Nudging someone who is waiting on you would have

landed badly. Answering him replaced the nudge.

• An existing client was waiting on a time commitment the CEO had made

himself for that day, with a hardware purchase on Sunday depending on it. She

is covered by a support ticket, not a CRM task, so nothing in the sales system

would ever have surfaced her.

---

Why this is the demo we chose

A clean run proves that a system can be built. It does not tell you whether the

system can be trusted with a compliance obligation.

What this run shows is narrower and more useful: the layer above the agents

re-derives what the agents claim, and when a claim survives on different

evidence than the one offered, it says so in writing. Four wrong statements were

already in the record — a fabricated price stamped "verified," an inflated

count, a correction that never happened, and two mailboxes swapped — and all

four came out of the same system on earlier days. The record is not clean. It is

audited, dated, and self-contradicting where it should be.

For a firm whose clients answer to the SEC, that distinction is the product.

Prospect research, start to finish

What this is

CyberSecureRIA runs an agent called RIA Lead Cleaner. When a new lead arrives — often

nothing but a name, a phone number and an email address — the agent profiles the firm

against public regulatory records, DNS, and the company's own web presence, then hands

back a structured brief before anyone picks up the phone.

**This page is a faithful re-run of that workflow using equivalent tooling, not a capture of

a production LibreChat session.** It was executed on 2026-07-31 against the same regulatory,

DNS, and CRM tools the production agent uses. It is reproduced here because the production

runs profile live, named prospects and cannot be published.

The subject is Fisher Investments — chosen deliberately. It is one of the largest

independent investment advisers in the United States, it is a matter of public record, and

it is not a CyberSecureRIA client or prospect. Every fact below comes from a public filing,

a public DNS record, or a public web page.

32 tool calls. 7 minutes 51 seconds. Six of those calls failed outright and seven more

returned nothing. What the run is meant to show is not that the tooling is fast — it is that

the agent kept going when the evidence ran out, and that it declined to answer two questions

it could not actually settle.

On the numbers below. Each step's duration is measured wall-clock time, captured with

timestamps around each batch of calls and divided evenly across the calls in that batch.

The figures therefore include the agent's own reasoning between calls, not tool latency

alone. They sum to 471,319 ms, which is the true end-to-end duration of the run.

Two categories of call are excluded from the step list: the timestamp calls added solely

to instrument this write-up, and the tool-schema lookups that load an API definition

before it can be used. Neither gathered any information about the subject.

---

Phase 1 — Identify the firm

Step 1 · SEC IAPD — firm name search

search_rias(name="Fisher Investments")
→ 1 result
  name:        FISHER INVESTMENTS
  legal_name:  FISHER ASSET MANAGEMENT, LLC
  CRD:         107342
  status:      Approved, effective 1987-03-26
  address:     6500 International Pkwy Ste 2050, Plano, TX 75093

Why this first. Registration is the one fact that gates everything else. A firm that is

not SEC-registered is either state-registered or not an adviser at all, and each of those

sends the research down a different path.

The reference run failed right here. In the production capture this demo is modelled on,

the equivalent search returned zero results, because the firm had renamed itself in 2018 and

the registry was keyed to the old name. A clean hit on step one is the lucky case, not the

normal one.

Steps 2–4 · Full record, CRM check, domain discovery

Three calls issued together:

get_ria_details(crd=107342)          → full adviser record
search_companies(name="Fisher")      → 0 results   [internal CRM]
web_search("Fisher Investments official website ...")
                                     → fisherinvestments.com

Not in the CRM. A zero here is a real answer, not a failure: it means this is a genuinely

new lead and no one has worked it before. On a live lead this is the check that prevents two

salespeople calling the same firm in the same week.

The registry gave the wrong website. The adviser record's website_address field reads

https://www.linkedin.com/in/ken-fisher/ — a personal LinkedIn profile, not the firm's site.

An agent that trusted that field would have spent the rest of the run scraping a social

profile. The domain had to be established independently before any DNS work could start.

This is the first of three points in the run where the authoritative source was wrong or

silent and the agent had to route around it.

---

Phase 2 — Infrastructure, from DNS alone

Steps 5–9 · A, MX, TXT, DMARC, NS

A     fisherinvestments.com     → 23.13.156.8
NS    fisherinvestments.com     → a1-159.akam.net, a4-64.akam.net, ... (6 records)
MX    fisherinvestments.com     → mxa-00160e01.gslb.pphosted.com  (10)
                                  mxb-00160e01.gslb.pphosted.com  (10)
TXT   _dmarc                    → v=DMARC1; p=reject; fo=1;
                                  rua=mailto:dmarc_rua@emaildefense.proofpoint.com

The apex TXT set returned 47 records. Grouped by what they reveal:

Signal	Records	Reads as
v=spf1 include:%{ir}.%{v}.%{d}.spf.has.pphosted.com ~all	1	Proofpoint macro SPF
SFMC-…	6	Salesforce Marketing Cloud
00D…=1TB…	18	Salesforce org verifications
MS=ms90876895	1	A Microsoft tenant exists
knowbe4-site-verification=…	1	KnowBe4 awareness training
atlassian-domain-verification=…	1	Atlassian collaboration suite
apple-domain-verification=…	2	Apple Business services
google-site-verification=…	3	Google Search Console
v=BIMI1; l=…/FI_Square.svg	1	BIMI — requires DMARC enforcement
opaque random-string tokens	13	Vendor domain-ownership proofs, issuer not identifiable

What DNS establishes without asking anyone. Akamai for DNS and content delivery.

Proofpoint as the inbound mail security gateway. DMARC at p=reject — the strictest

setting, meaning unauthenticated mail claiming to be from this domain is discarded rather

than quarantined — with Proofpoint Email Fraud Defense collecting the reports. A published

BIMI record, which registrars only honour on top of DMARC enforcement. Eighteen Salesforce

org tokens, which implies a large multi-org Salesforce estate rather than a single CRM.

>

For a security-services conversation this is the whole opening position: a firm at this

maturity does not need to be told what DMARC is, and an agent that opened with that pitch

would have disqualified itself in a sentence.

Steps 10–13 · The dead end that mattered

Two DNS facts blocked the obvious next question — *what actually runs their email?*

The MX records point at Proofpoint, which is a gateway sitting in front of the real mail

platform, not the platform itself. And the SPF record is Proofpoint's macro form

(%{ir}.%{v}.%{d}), which expands per-message at validation time and deliberately publishes

no vendor list. In the reference run against a small firm, SPF alone exposed HubSpot and Brevo

in one lookup. Here, both of the usual answers were unavailable by design.

So the agent probed four Microsoft 365 tells directly:

CNAME  autodiscover.fisherinvestments.com               → NXDOMAIN
CNAME  enterpriseregistration.fisherinvestments.com     → NXDOMAIN
CNAME  selector1._domainkey.fisherinvestments.com       → NXDOMAIN
CNAME  selector2._domainkey.fisherinvestments.com       → NXDOMAIN

All four absent.

This is the most important annotation on the page.

>

The MS=ms90876895 token proves a Microsoft tenant has verified this domain. It does not

prove that mail is delivered by Exchange Online — that token is written by any Microsoft

service claiming the domain. The four records that *would* have settled it are all missing.

>

The available move was to write "Microsoft 365" in the brief. One token pointing that way,

no token contradicting it, and no salesperson would ever check. The agent instead recorded

the mail platform as not determined from DNS, and listed the four probes it ran.

>

A profile is used to plan a conversation with a stranger. A guess dressed as a finding is

worse than an acknowledged gap, because the gap gets asked about on the call and the guess

does not. Getting this wrong in front of a prospect's IT director costs the meeting.

---

Phase 3 — Three failures in a row, and the way around them

Steps 14–19 · Everything breaks

fetch  adviserinfo.sec.gov/firm/summary/107342   → page chrome only, no firm data
fetch  fisherinvestments.com/en-us               → timeout (60s)
fetch  fisherinvestments.com/en-us/about/…       → timeout (60s)
fetch  fisherinvestments.com                     → timeout (60s)
fetch  reports.adviserinfo.sec.gov/…/107342.pdf  → 2.1 MB binary, unreadable

Five of six fetches produced nothing usable. The SEC's public firm page is a JavaScript

application that renders its data client-side, so a fetcher receives the navigation shell and

no content. The firm's website timed out three times at three different URLs. The Form ADV

itself downloaded, but arrived as raw compressed PDF streams the fetcher could not decode.

Step 16 · Recovery — the API behind the app

fetch  api.adviserinfo.sec.gov/search/firm?query=107342&includePrevious=true
→ FISHER INVESTMENTS
  CRD 107342 · SEC file number 801-29362 · Plano, TX
  Registration: Active · Disclosures: N · Branch count: 2,242

Why this worked. The page that failed and the endpoint that succeeded serve the same

data; the page just renders it in the browser. Querying the interface underneath returned

clean JSON in one call — and produced the SEC file number, 801-29362, which the local

registry mirror did not carry at all.

A second firm came back in the same response — an unrelated Hong Kong adviser whose SEC

file number, 802-107342, happens to contain the digits of Fisher's CRD. The match had to be

confirmed on the CRD field rather than on result order. Taking row one on faith is how two

firms become one profile.

Steps 18, 20–26 · Recovery — read the filing locally

The Form ADV fetch failed, but the 2.1 MB response was written to disk. That was enough:

pdftotext -layout fisher_adv.pdf fisher_adv.txt     → 4,813 lines of readable text

The failure was in the reader, not the artifact. The document had been retrieved

successfully; only the conversion step could not handle it. Re-fetching would have failed

the same way forever. Extracting the already-downloaded bytes with a local tool turned the

single richest source in the entire run — the firm's own sworn filing — from a dead end into

the backbone of the profile. Seven follow-up reads pulled Items 1, 3, and 5 out of it.

Form ADV, filed 2026-04-02 (Other-Than-Annual Amendment):

Item	Value
Regulatory assets under management	$— — 100% discretionary
Total accounts	422,516
Employees	4,369 (1,948 performing advisory functions)
Registered reps of a broker-dealer	0
Employees registered as IARs with states	2,520
Total clients	~199,922
— high-net-worth individuals	125,844 · $—
— individuals (non-HNW)	73,217 · $—
— state / municipal entities	20 · $—
— pooled vehicles	46 · $—
Clients who are non-US persons	24%
State of organization	Delaware
Fiscal year end	December
Offices beyond the principal office	11

---

Phase 4 — What the stale copy would have told us

The registry the run started from is a local mirror, and its most recent filing for this

firm was dated 2024-07-29. The live filing is dated 2026-04-02 — roughly twenty months

newer. Same fields, same firm, both figures internally consistent:

Field	Mirror (2024-07-29)	Live ADV (2026-04-02)	Difference
Assets under management	$—	$—	+$— (+39.6%)
Total accounts	161,361	422,516	+261,155 (+161.8%)
Employees	3,525	4,369	+844 (+23.9%)
Advisory employees	1,613	1,948	+335 (+20.8%)
HNW clients	91,826	125,844	+34,018 (+37.0%)

This is why the ADV retrieval was worth three failed fetches. Steps 1 and 2 returned a

complete, well-formed, plausible adviser record. Nothing about it looked stale. Had the run

stopped there — and it easily could have, since the first call succeeded — the brief would

have understated the prospect by $— and undercounted its accounts by a factor of

2.6.

>

A cached copy of a public record fails silently: it reads exactly like a current one. The

only defence is to go back to the source when the number is load-bearing.

The contradiction the run did not resolve

The live search API reported 2,242 branches. The firm's own ADV, Item 1.F(5), reports

11 offices beyond the principal office. The mirror said 14.

These are not the same measurement, and the run says so rather than picking one.

The mirror's 14 and the ADV's 11 track the same field across two filing dates. The 2,242 is

a different quantity from a different system — a count of branch registrations in CRD, which

for a firm with 2,520 state-registered adviser representatives plausibly includes individual

representatives' registered locations.

>

Reported as a staleness finding, "14 offices became 2,242" would have been a striking and

completely false claim. The two numbers are recorded with their sources and the mismatch is

marked unresolved. Surfacing a contradiction is a finding; inventing a reconciliation is not.

---

Phase 5 — Close the remaining questions

Steps 27–29 · Directory checks

broker-dealer registry      → ERROR: server API key not configured
state adviser registry      → 0 results
fee-only planner directory  → 0 results

A tool outage is not an unanswered question. The broker-dealer registry was unavailable,

so the affiliation question had to come from elsewhere — and it already had: Form ADV Item

5.B(2) reports 0 employees registered as representatives of a broker-dealer. The answer

was in a source already on hand.

>

The two zeroes are both correct and both meaningful. No state registration is what an

SEC-registered adviser should show. Absence from the fee-only planner directory is

consistent with an AUM-fee model rather than a flat-fee planning model.

Steps 30–31 · Public profile, and why the website never loaded

web_search("Fisher Investments founded ... headquarters Plano")
→ Founded 1979 by Ken Fisher. HQ relocated to Plano, TX in 2023 from Camas, WA.

curl -I https://www.fisherinvestments.com/en-us   → HTTP 403 in 0.33s

The site was never down. Three 60-second timeouts look like an unreachable host. A direct

status probe returned 403 Forbidden in a third of a second — the site is up and deliberately

refusing automated clients, consistent with the Akamai bot management in front of it.

>

The distinction changes the brief. "Their website is down" is an embarrassing thing to put in

front of a prospect. "Their web tier actively blocks automation" is an accurate observation

about a firm that takes its perimeter seriously, and it explains why every company fact in

this profile came from the regulatory record and third-party coverage instead.

Step 32 · Local time

Plano, TX → America/Chicago → 10:40 PM CDT

Whether it is a reasonable hour to call is the last thing the agent checks and the first

thing a salesperson needs.

---

The finished profile

Fisher Investments · legal name Fisher Asset Management, LLC

Registration	SEC-registered · CRD 107342 · file 801-29362 · approved 1987-03-26 · no disclosures
Assets	$—, entirely discretionary, across 422,516 accounts (ADV 2026-04-02)
Clients	~199,922, of which 125,844 high-net-worth; 24% non-US persons
People	4,369 employees · 1,948 advisory · 2,520 state-registered IARs · 0 broker-dealer reps
Founded	1979 by Ken Fisher
Headquarters	Plano, TX (relocated 2023 from Camas, WA) · 11 offices beyond principal
Organization	Delaware · fiscal year ends December
DNS / CDN	Akamai (Edge DNS + content delivery)
Mail security	Proofpoint gateway · DMARC p=reject · Proofpoint Email Fraud Defense · BIMI published
Platforms seen	Salesforce (18 org tokens) · Salesforce Marketing Cloud · Atlassian · KnowBe4 · Apple Business · Google Search Console · a Microsoft tenant
Web tier	Returns 403 to automated clients
In our CRM?	No

Recorded as undetermined:

• Mail platform behind the Proofpoint gateway. Four Microsoft 365 indicators probed, all

absent. The MS= token proves a Microsoft tenant, not Exchange Online delivery.

• Office count. ADV Item 1.F(5) says 11; the CRD-derived branch count says 2,242. Different

measurements from different systems; not reconciled.

Deliberately excluded. The Form ADV carries the chief compliance officer's name, direct

address and email address, all of it public record. Individual contact details are left out of

this published version.

---

What this demo is evidence of

Nineteen of the thirty-two calls returned data. Six failed. Seven returned nothing. The value

is concentrated almost entirely in how the thirteen non-answers were handled:

1. The authoritative record was wrong. The SEC registry's website field pointed at a

personal LinkedIn profile. The domain was established independently.

2. The authoritative page returned nothing. The SEC firm page renders client-side; the

agent queried the interface beneath it and gained a field the mirror never had.

3. The document could not be read. The ADV was retrieved but not parsed; extracting the

saved bytes locally turned the run's richest source from a failure into its backbone.

4. The cached record was silently stale. Twenty months out of date and entirely

plausible-looking, understating the prospect by $—.

5. The evidence did not reach the answer. Four probes for the mail platform, all negative,

recorded as undetermined rather than guessed.

6. Two sources disagreed. 11 offices against 2,242 branches, reported as a mismatch with

both sources named rather than resolved into a false headline.

7. A failure was misdiagnosed and re-checked. Three timeouts looked like an outage; a

status probe showed a live host refusing bots.

Any one of those, handled by taking the first plausible answer, produces a brief that reads

exactly as well as this one and is wrong. That is the case for verification over automation:

the difference is invisible on the page and decisive on the call.

Demo B — Ticket enrichment: four words in, a briefing out

Ticket: T20260730.0100 · Opened: 30 July 2026, 20:12:48 UTC ·

Enrichment posted: 20:15:10 UTC — 2 minutes 22 seconds later ·

Closed: 20:30:39 UTC, 0.35 billable hours

A real inbound support request from a registered investment adviser, and the

briefing that was waiting on the ticket before any technician opened it.

Client and personal names, firm names, domains and email addresses have been

replaced with role labels. Ticket numbers, dates and timestamps are unchanged.

---

Two columns

Column A — what the client sent

Subject line, in full:

Cowork not showing up

Body, in full:

Hi team –

>

Any idea why co-work is not appearing for me in the app? See below:

>

[inline image]

[inline image]

That is the entire request. Sender: the firm's principal advisor. Route: the

shared help address, into the Helpdesk queue. Two screenshots, no license

information, no product tier, no description of where he was looking, no

statement of what he expected to see.

---

Column B — what the technician saw before touching it

Assembled automatically from the documentation system, the ticket history

across the whole client base, and the vendor's own documentation, and posted to

the ticket as a note.

The client's documented environment

Pulled from the IT documentation platform (30 documented assets for this

organization):

Area	What is documented
Productivity platform	Microsoft 365 — confirmed as the email and productivity platform
Applications	Microsoft Office suite, video conferencing, screen recording, text expansion, a marketing-automation vendor
Network	Firewall, 24-port PoE switch, two access points, default and guest VLANs, a full-duplex fibre WAN circuit
Remote access	The managed SASE / VPN client
Data	Primary SharePoint site, third-party Microsoft 365 SaaS backup
Print / endpoints	Three documented printers, including two remote-worker printers
Credentials	A tenant global-admin entry exists in the vault

Credential handling. The enrichment records that a global-admin entry

*exists* and where it lives. It never retrieves a password value. Secret

material is not read into an AI context in this workflow.

A documented absence, stated as one. This organization has **no license

inventory record**. The enrichment said so directly rather than reasoning past

it: license state cannot be confirmed from documentation, so it must be checked

in the tenant. (Independently re-verified for this page: 30 flexible assets on

the organization, none of them a license record.)

Prior tickets across the entire client base

This is the part a technician cannot do from memory. The same request has come

in before — from different clients, months apart, handled by different people.

• A law-firm client, 22 June 2026 (T20260622.0110). Same feature, same "it

is not appearing" complaint. That firm *did* hold a valid license for the

product — two seats on an annual term. The resolution path is written out in

full on that ticket: the "request access" button the user sees is what the

vendor shows when tenant-side usage-based billing has not been enabled;

enabling it is billable configuration work, quoted at 1–4 hours at $—/hr;

and the running cost afterwards is consumption-based and unbounded — the

technician's own written estimate to that client was *"anywhere from $— to

$— a month depending on what you tell it to do."* **The client declined

and the ticket closed.** The wording used to explain that is available to

re-use.

• A second advisory client, 22 July 2026 (T20260722.0169) — open at the time.

Same feature. In that tenant a cloud subscription turned out to be a

prerequisite, ordered during the session. Names the internal subject-matter

expert to consult before repeating the work.

• This contact's own open tickets: a firewall quote (15 July) and a SASE

client re-install (16 July), both still open. A separate open ticket for

another user at the firm on docking-station monitors.

• This contact's recent closed history: five tickets in three weeks,

including a three-hour ethernet/DHCP failure through a dock on a new laptop

(9 July) and duplicate mapped-drive folders tied to that machine (10 July).

Why this column is the valuable one. The June precedent contains a priced,

written, client-accepted explanation of a consumption-billing model — produced

once, by one technician, on a different client's ticket, five weeks earlier.

Without retrieval it exists only in that technician's memory. With it, every

technician starts from it.

Vendor documentation

The enrichment cites the vendor's live administrator documentation rather than

recalling how the product works. Re-fetched on 31 July 2026 for this page

(learn.microsoft.com/en-us/microsoft-365-copilot/cowork/cowork-admin-governance,

page dated 17 July 2026), the administrator page states:

"To allow users to access Cowork, admins must enable usage-based billing."

"If an admin makes Cowork discoverable to end users but doesn't enable

usage-based billing, end users can request to access Cowork directly in the

app. Admins need to review and approve requests based on policy, cost, and

compliance."

It also lists where end users reach the feature — browser, desktop app, mobile

app — which covers the possibility that the user simply looked in the wrong

place.

What the enrichment said it did not know

Written by the enrichment, in its own output, under a heading it generates on

every ticket:

• License state for this user is unknown, and it is the most important unknown.
• No license inventory record exists for this organization, so documentation

alone cannot settle it.

• The two screenshots could not be read. "Unknown what exactly he is

seeing." It recommended asking for a screen recording.

---

What actually happened — and why we are showing it

Eighteen minutes after the enrichment posted, a technician remoted onto the

machine. The full resolution note:

Remoted on to the computer. Found that containers were not enabled in Windows

features. Enabled and rebooted. Verified the feature is now available.

0.35 hours. Closed same day.

The enrichment's leading hypothesis — that the user had no license — was wrong.

Its five suggested next steps did not contain the actual cause. A local Windows

optional feature was disabled on one machine, which is visible in a screenshot

and in a remote session, and is not visible in any documentation system, ticket

history, or vendor page.

Two further things the enrichment carried that a reviewer should catch:

• It described the feature as being in preview and stated that an AI

subprocessor had to be *enabled* or the feature would not function. Re-reading

the vendor page on 31 July 2026: the feature is

"now generally available," and the model family in question is a **default-on

setting an administrator may turn off**, not one they must turn on. The June

precedent was carried forward into a July ticket without re-checking whether

the vendor page still said the same thing. It did not.

• The strongest single input to the diagnosis — the two screenshots the client

actually sent — was the one input the enrichment could not read.

We are not presenting this as the system working perfectly. We are presenting it

because it is the ordinary case, and because it is the argument for the limit

below.

---

The limit we have deliberately not crossed

CyberSecureRIA does not let AI answer tier-one tickets. No agent replies to

a client, closes a ticket, or takes an action in a client tenant. Enrichment is

posted as an internal note; a human reads it, decides, and answers.

This is a decision, not a gap in the roadmap. The reason is specific: **we

cannot yet document the safety case.**

Our clients are registered investment advisers. Their obligations under

Regulation S-P and the books-and-records rules run through us as a service

provider. Anything we automate in front of a client has to be describable to

their compliance consultant and defensible to an examiner — what it can do, what

it cannot, how a wrong answer is caught, and who is accountable when one gets

out. We can write that document for retrieval and drafting. We cannot yet write

it for autonomous client contact, and until we can, we are not shipping it.

This ticket is the argument in miniature. The enrichment was fast, well

sourced, accurate about the vendor's requirements, explicit about what it did

not know — and its leading hypothesis was wrong, because the cause was a toggle

on one laptop. Had it been permitted to answer, this client would have received

a well-written, correctly cited message telling him he probably needed to buy a

license. He would have believed it. He was 18 minutes away from a technician who

fixed it for 0.35 hours.

Where AI is allowed to act on its own, at CyberSecureRIA: retrieval,

enrichment, cross-client precedent search, vendor-documentation lookup, drafting

into a human's queue, and internal audit records.

Where it is not: replying to a client, closing a ticket, changing a client

tenant, or any action a client sees before a human has.

---

Where the enrichment comes from

Every element in Column B is a live query against a system CyberSecureRIA

already operates — the PSA (ticket history across all clients, plus semantic

retrieval of similar tickets), the IT documentation platform (organizations,

configurations, documented assets, credential metadata), and the vendor's own

public documentation. No knowledge is authored into the agent. When a vendor

changes a page, the next ticket sees the new page — which is exactly the check

that was skipped above, and the reason it is a human who reads the result.