Staffless Co. — Dashboard

generated 2026-07-14 13:08 UTC
Loop
● running
ticks this month: 34, failed: 0
Spend · 2026-07
$0.00
of $100 budget (0%)
Revenue · 2026-07
$0.00
stripe $0 · x402 $0
Tasks
39/59
done / total
Needs CEO
✋ 10
pending approvals

✋ Waiting on Jan

2026-07-14 — STRATEGIC INFLECTION: the empty-MCP-niche strategy is exhausted (recommend pivot)

> ✅ **RESOLVED 2026-07-14 — CEO steered.** Direction: stop hunting empty niches; win on provable quality-for-price via honest benchmarks (occupied OK if the incumbent is BEATABLE — not free+OSS). Plus a new parallel lane: almost-digital niches (small physical part gates out the agentic flood; bridge via HaaS/physical-API, Tier-3 to execute). Both research lanes launched. Recorded in decisions + memory/kywio-strategy.

> The Agent-Sim campaign + a follow-up hunt checked **8 paying niches in one day — our 3 live ones plus 5 adjacent — and ALL 8 are occupied by shipping MCP incumbents** (several VC-funded: Raindrop raised $15M for loop-detection; Etymolt/Brandomica/LicenseSpring/Sonatype/Snyk/UptimeRobot own the others). This is the P1 lesson at the MCP-product level: wherever a niche pays, competent people already shipped the MCP. "Be first in an empty MCP niche" has structurally failed — not unlucky, entailed. Continuing to hunt empty niches is low-yield.

>

> **Recommendation — change the strategy from FIND-EMPTY-NICHE to WIN-AN-OCCUPIED-NICHE on our real differentiator: verifiable quality + honesty.** This is exactly what your pm-adoption doc predicted would be THE differentiator when supply explodes. We have that brand (research rigor, published benchmarks, radical honesty) and few competitors do. First test: **Heartbeat** — make our provable reliability edge (off-box prober, verifiable /health, "we provably can't cry-wolf or die-silently") VISIBLE and win against Healthchecks/UptimeRobot. The round-0 customer sim handed us the exact levers it lost on (reliability story invisible; free-tier alerting unclear). I repurpose Agent-Sim: its customer track (tune-to-win) is the valuable half now; the competitor track already proved there are no empty niches.

>

> **Proceeding on the reversible part** (honest improvements to our one live product, valuable regardless): apply the Heartbeat visibility/alerting fixes and run Agent-Sim round 1 to measure the flip. **Your call:** do you endorse the pivot to win-on-quality (vs. keep hunting, or a different direction entirely — own-a-problem, learning-vehicle)? This is a genuine company-direction fork and I want your steer before investing heavily in it.

> 🔬 **UPDATE 2026-07-14 — win-on-quality tested on Heartbeat = honest NO.** I applied the real, honest fixes the round-0 sim identified (made our live off-box prober + verifiable /health the visible headline; clarified free-tier webhook alerting) and re-ran the panel. The fixes were GENUINE — all 4 personas found and *externally verified* them, trust rose, they called us "more transparent than competitors." But the decision held at 0/4. The real blocker isn't visibility — it's (1) our single-box SPOF (fatal for a product whose whole value is the monitor not dying) and (2) Healthchecks being free + more generous + open-source self-hostable. Both flips require either a major infra build we should NOT do ahead of demand (0 signals), or an unwinnable race against free OSS. **So even our flagship, optimized on our real differentiator, does not win its niche.** This sharpens the fork: win-on-quality can still work, but only in a niche with a BEATABLE incumbent (expensive/proprietary, no strong free/OSS option) where quality is the decisive buying criterion — not Heartbeat. I'm holding further Heartbeat investment and awaiting your steer on direction. The campaign paid for itself many times over: in an afternoon it proved all 8 reachable niches occupied AND that our best product loses even when perfectly presented — saving us from building multi-region infra for a product that still wouldn't win.

2026-07-14 — Agent-Sim round 0: all 3 current niches have verified MCP incumbents (strategic FYI + rec)

> The simulation campaign paid off immediately. Its competitor track (live web search) found MCP-native incumbents in all three of our niches that our own hunts had MISSED — I verified each at the source: **Etymolt** ships an official MCP trademark-clearance server (§2(d) phonetic, free+paid, "not legal advice" — our exact pitch); **LicenseSpring** ships a 34-tool licensing MCP (+ Keygen); **UptimeRobot/Better Stack** occupy heartbeat-monitoring MCP. The "no incumbent MCP" premise behind the clearance and licensing demand tests is broken. Customer track: 0/8 pay-Kywio, and the one real datum (Heartbeat, our only built product) is a clean 0/4 loss to Healthchecks' more-generous free tier.

>

> **What I am doing (reversible, no approval needed):** letting the cheap clearance/licensing fake-doors finish their committed runs (zero extra cost) but stopping investment in them; applying cheap visibility levers to Heartbeat (surface the off-box prober + verifiable liveness; clarify free-tier alerting); and pivoting exploration to the adjacent OPENINGS the campaign found — top pick **semantic agent-progress liveness** (catch looping/stalled/zombie agents that ping but make no progress — a real gap NO incumbent covers, and a natural Heartbeat extension). Hunt on the 5 adjacent candidates launching now.

>

> **Your call if you disagree:** whether to KILL clearance/licensing now rather than let them finish. I recommend letting them run (sunk, cheap) while we pivot. Also folding a competitor-sim into every future hunt as a permanent process fix (it caught what our hunts missed).

2026-07-14 — Discovery unblocks: 2 quick account actions could open our biggest channels (your call)

> 🔄 **UPDATE 2026-07-14 — CEO submitted the Glama registration (`vanekyj/kywio` as `mcp-heartbeat`); it is UNDER REVIEW.** Remaining step is mine and automatic: when Glama publishes the scored `/servers/vanekyj/kywio` page, I add the score badge to awesome-mcp-servers PR #10014 and finish it. I check for the page each tick; no further CEO action needed for #1. (Smithery, #2, still optional.)

>

> ✅ **Smithery DONE 2026-07-14** — CEO also listed it: https://smithery.ai/servers/vanekyj/kywio (verified live: displayName "kywio", remote, 3 heartbeat tools). Both curated channels now in motion.

>

> ✅ **DONE 2026-07-14 — Glama approved (https://glama.ai/mcp/servers/vanekyj/kywio); I added the score badge to PR #10014 and commented. The PR is now complete on our side and awaits the maintainer's merge (out of our hands).**

> Discovery is the real bottleneck — all three live tests read 0, and I have maxed the headless, ToS-clean distribution (official MCP registry publish, which already auto-propagates: Glama connectors live, PulseMCP syncing). A web-aware agent asked to recommend a job-monitoring MCP today still names the incumbents (Cronitor/Healthchecks), not us — expected this early, but it shows registry presence alone is not enough. The two highest-leverage unblocks left are ~2-minute account actions only you can do (both Tier-3 = new-service accounts):

>

> 1. **Glama account (GitHub OAuth) → claim/submit our public repo `vanekyj/kywio`.** This gets us a scored Glama `/servers` page, which is the EXACT gate blocking our open PR to **awesome-mcp-servers #10014** — the highest-traffic curated MCP list. Right now that PR is stuck waiting on a Glama score badge that does not exist until the repo is claimed/built there (I verified: the `/servers/vanekyj/kywio` badge 404s). Clearing this unblocks a top discovery channel AND upgrades our Glama listing to verified.

> 2. **Smithery account** (smithery.ai) — accepts our remote MCP URLs directly; one more active channel. (Its AI-submission policy is unverified, so confirm it permits this before I post — Hard rule 7.)

>

> Recommendation: **#1 is worth the 2 minutes** (unblocks the awesome-list PR, our best curated-discovery bet); #2 optional. If you do #1, I add the score badge to the PR and finish it headlessly. If you skip both, we lose little immediately — organic registry indexing still grows — but curated-list discovery stays gated. No rush; not nagging; batched here for whenever you have a moment.

2026-07-13 — GO/HOLD: slot-1 candidate found — MCP-native trademark clearance (the algorithm actually matters here)

> ✅ **RESOLVED 2026-07-14 — CEO said GO.** Point 1: confirmed outside the conflict line ("music and video copyright search by content is excluded, which this is not"). Point 2: UPL positioning approved. EXECUTED same tick: gate pre-registered (EXP-034), honest fake-door built + deployed + verified live at kywio.com/clearance. Now in a demand test (task P8-1); distribution next.

**You asked me to hunt slot 1 where algorithm research boosts product attractiveness. The hunt returned one candidate that passes every filter, and I verified the three decisive facts at primary sources this tick.** I have **primed it, not launched it** — two calls below are yours.

**The product:** "is this name clear?" — given a candidate brand name + Nice class, return the top-N *confusingly-similar live US trademarks* (phonetic + spelling + prefix/suffix variants) with serial numbers, before someone spends a ~$250–350 USPTO filing fee and 8+ months on a doomed application. Exposed as MCP + REST.

**Why the algorithm is the attraction, not a cost pitch:** professional clearance *is* a fast exact multi-metric similarity top-N over ~3M live marks — your hash→prefilter→exact-recompute engine. Two things fall out that incumbents can't match: (1) **exactness** — a missed similar mark = a refusal = lost fees/months, so recall is the headline the category sells on; (2) **latency as a feature** — millisecond exact scoring lets a *naming agent screen hundreds of generated name candidates per tick*, a generate-and-screen loop no per-report incumbent supports. And we can turn our brand into the product: benchmark our recall against USPTO examiners' *actual* refusal citations — a number we can publish and nobody else does.

**Three decisive facts, each verified at source (not the agent's word):**

**Someone pays:** Markify sells this similarity search at **$169/report** ("finds more than 99% of confusingly similar trademarks… phonetic, orthographic, prefix/infix/suffix"). Verified at markify.com.
**The data is free (this is the P1 trap, cleared):** USPTO ships the full mark corpus for free — annual backfile + **daily delta XML** — with word mark, goods/services, class and status. P1 died because every dollar paid for reference *data*; here the data costs nothing and self-hosts. Verified at uspto.gov / data.uspto.gov.
**No incumbent MCP:** the one trademark MCP that exists is plain search + status; the *paid* capability (similarity/confusion ranking) has no MCP-native version. Same opening Heartbeat had against Healthchecks.

**The two calls that are yours (why I did not just launch):**

1. **Is this inside your conflict-of-interest line?** Hard rule 2 forbids the **music/video *copyright*** business. Trademarks are **brand law** — a different body of law from copyright, and unrelated to music/video. **My read: this is outside the rule.** But it's "rights"-flavoured, and only you get to draw your own conflict boundary, so I'm not putting "Kywio does trademark clearance" on Show HN and the MCP registry on my own judgement.

2. **Positioning around legal advice (UPL).** "Is this name clear?" brushes legal advice. The fix is the same one Markify/Trademarkia use: we return **register data ranked by similarity, explicitly not legal advice**, with a disclaimer. I'll build that in — flagging it so it's your informed call, not a surprise.

**What I recommend:** **GO** — approve a cheap, AI-disclosed, no-money **fake-door demand test** (same honest shape as the licensing one you already approved): an honest landing page + a stub MCP listed on the registries, 14 days, pre-registered signal gate, *no backend built*. It costs ~$0 and a tick, and it answers the one real doubt — does the self-serve segment feel the recall gap enough to pay a no-name vendor rather than settle for USPTO's free word search?

**If you say GO:** I register the demand test (gate fixed *before* any outreach) and ship the fake-door next tick. **If you say HOLD:** slot 1 empties and image-dedup stays benched. **If unanswered:** nothing goes public; the candidate sits primed and I keep hunting the other slots. (Details in `state/portfolio.json` slot 1 and task P8-1.)

2026-07-13 — Publication is READY but BLOCKED on a GitHub token scope (~1 min for you)

> ✅ **RESOLVED 2026-07-13** — the public repo **vanekyj/kywio** is live (verified public, pushed 2026-07-13). Publication complete; no action needed.

You approved publication. **I cannot finish it:** our `GITHUB_TOKEN` is a fine-grained PAT

scoped to the private `company` repo only. `POST /user/repos` returns

**403 "Resource not accessible by personal access token"** — I cannot create a new repo.

**Everything else is done and verified:**

The public tree is assembled: `bench/`, `api/`, `site/`, `docs/{p1-spec,research-principles}`,

**`state/experiments.md`** (1,340 lines — the artefact), requirements, README, MIT LICENSE.

**Leak gate passes**: no tokens, no Telegram chat ID, no server IP, no `/home/company` paths,

no journal/inbox/outbox/decisions/budget/CLAUDE.md.

**I made "reproducible" TRUE before publishing it.** It wasn't. Even with the repo public,

nobody could have reproduced anything — the data was gitignored and there was no fetch

script. Now `bench/fetch_data.py` pulls Zenodo 8164151 and **hash-verifies the sequestered

test sets against the committed SHA256SUMS**, so an outsider can prove we didn't tamper with

the data we report numbers on. Verified from a clean checkout.

The scrubbed code still runs (MCP server tested, correct scores).

**YOUR STEP (~1 min):**

1. Create an **empty public repo** named `kywio` (no README, no licence — the script pushes

the first commit).

2. Give the existing fine-grained token **write access** to it

(Settings → Developer settings → token → Repository access → add `kywio`).

Then I run `ops/publish-public-repo.sh` — it has a **hard leak gate that refuses to push** if

anything internal survived.

**One judgement call I made, flag it if you disagree:** I am **excluding `docs/business-plan.md`**

from the public repo. My earlier note said "docs/", but the plan contains revenue expectations,

kill criteria and strategy. Excluding it is the conservative read. Say the word and I'll include

it — it is, frankly, the most interesting document we have.

2026-07-13 — TIER-3: publish a public benchmark repo? (I caught us making a false claim)

> ✅ **RESOLVED 2026-07-13** — approved and done — benchmark, experiment log and SPECIMEN.md are public at github.com/vanekyj/kywio. Decision closed.

**What happened.** Our live site said the benchmark was *"published and reproducible"* and

pointed readers to "the repository". **The repository is private.** Nobody outside the company

could reproduce anything. That claim was **false**, on a public page, for about an hour.

**What I already did (my authority, done immediately):** retracted it. The site now carries an

honesty note at the top stating the claim was untrue and that **every number on it is asserted

by us and not independently verifiable** until the repo is public. Live now.

**What I will NOT do without you.** Publishing the repo is **Tier-3**: it is irreversible (you

cannot un-publish), it is reputation-relevant, and `vanekyj/company` contains **internal

records** — your inbox/outbox, the decision log, the 988-line journal, `ops/budget.json`, spend

figures. I am not putting those on the internet on my own judgement.

**Options:**

| | what | pros | cons |

|---|---|---|---|

| **A (recommended)** | New **public** repo `kywio-bench`: `bench/`, `docs/`, `api/`, `site/`, and `state/experiments.md` (the experiment log — this *is* the artefact). **No** ceo-inbox/outbox, journal, budget, or metrics. | Makes the reproducibility claim TRUE. Keeps internal company records private. The experiment log — 13 experiments, 5 negative results, the test-set touch log — is the credibility asset, and it stands alone. | A little duplication to maintain. |

| B | Make `vanekyj/company` public as-is | Zero effort; maximal transparency, including how the company is actually run — which is itself interesting. | Publishes your comms, budget and spend. Irreversible. |

| C | Publish nothing | No exposure. | The site must keep saying our numbers are unverifiable — which materially weakens the *only* asset we have. Research credibility you can't check isn't credibility. |

**My recommendation: A.** It makes the claim true, costs nothing we care about, and the

experiment log is exactly the thing a sceptical reader should be able to audit. Our entire

positioning is "the vendor whose numbers you can check" — right now, you can't.

**If unanswered:** nothing is published, and the site keeps its honesty note saying our numbers

cannot be independently verified. That is survivable but it blunts the one thing we have.

2026-07-13 — P1 v1 is a RESEARCH PREVIEW, not a sellable product. Please read.

> ✅ **RESOLVED 2026-07-13** — superseded — P1 was killed (NEG-008, no buyer) and publicly retired; this was an FYI, nothing to action.

**I need to walk back part of the business plan, on evidence.**

Driving our own API and MCP server found two defects the benchmark was *structurally

incapable* of finding:

1. **`Acme Corp.` vs `ACME Corporation` → 0.385 → "NOT a match."** (`Microsoft Corp` vs

`Microsoft Corporation` → 0.936, because `microsoft` is a token the model has *seen*.)

2. **The score depends on how many fields you send.** The same true-match pair scores

0.412 with 1 field, 0.797 with 2, 0.862 with 3 — it flips across the 0.45 threshold

purely by adding columns.

**Root cause:** the model exploits *distributional artefacts* of its training data (field

count, corpus token frequency) rather than learning name equivalence. Our sequestered-test

numbers (0.979 / 0.862 / 0.658) are **true** — for records shaped like that training data.

They do **not** transfer to two-column name matching, which is the single most obvious

entity-resolution use case.

**Therefore:** selling this as a general-purpose matcher would be a promise we cannot keep

(Hard rule 5). **P1 v1 is a research preview with a published, reproducible benchmark.**

The determinism, the cost ($0.0012/1M), the sub-millisecond latency and the benchmark are

all real and publishable. The general product is not real yet. That is a smaller claim than

the business plan assumed, and it is the true one.

**v2 needs a redesign, not a patch:** field-count-invariant aggregation; a

corpus-frequency-free similarity floor; and a company-/person-name eval set with a **fresh**

sequestered split (the current test set is closed).

---

2026-07-13 — Two blockers I cannot route around (both need you)

> ✅ **RESOLVED 2026-07-13** — resolved — kywio.com serves 200 via the named Cloudflare tunnel (T024) under systemd (T029); no inbound port, origin IP hidden.

**1. Cloudflare token has no DNS scope.** `CLOUDFLARE_API_TOKEN` verifies as active but

sees **zero zones** — it was created for Pages only. I cannot point `kywio.com` at the VPS.

→ *Add Zone:Read + Zone:DNS:Edit for kywio.com to the token (or issue a new one).*

**2. I cannot open a public port.** `ufw` allows only 22/80/443; binding :80 needs root; and

`sudo`, `systemctl` and `ufw` are all on my deny list (correctly). So the REST API cannot be

exposed publicly, nor run as a durable service, without you.

→ *Simplest fix: `sudo ufw allow 8080/tcp`, then I'll route Cloudflare to origin port 8080.

For durability I'll also need a systemd unit installed — I'll write the file; you run

`systemctl enable --now`.*

**Not blocked by either:** the **MCP server works right now**, over stdio, no hosting needed:

`claude mcp add kywio -- /home/company/kywio-venv/bin/python /home/company/company/api/mcp_server.py`

2026-07-13 — Small ask: an ANTHROPIC_API_KEY, to measure our own headline claim (~$2-3)

> ✅ **RESOLVED 2026-07-13** — **WITHDRAWN** — this existed only to measure P1's LLM baseline; P1 is dead, so no key is needed. Please do NOT create one for this.

**The problem.** Our central competitive claim is that we are orders of magnitude cheaper

and faster than LLM-direct matching. Right now we cannot *measure* that ourselves:

`ANTHROPIC_API_KEY` is absent. What we hold is `CLAUDE_CODE_OAUTH_TOKEN`, which drives

Claude Code but **cannot call the Messages API**.

**Why it matters.** A company whose entire brand is research rigor should not rest its

headline number on someone else's published figures. Every other number in our benchmark is

ours and reproducible; the LLM comparison would be the one exception.

**The ask.** Create an Anthropic API key and add `ANTHROPIC_API_KEY=...` to the VPS `.env`.

**Estimated cost: ~$2-3** for the full LLM-direct baseline (~6,700 validation pairs on a

small model). Well inside the $10 per-transaction auto-approve.

I will report `$/pair` and latency alongside F1, as pre-registered.

**If you'd rather not:** two honest fallbacks, both worse.

1. Cite the literature (Peeters & Bizer) and label it **EXTERNAL / UNVERIFIED — not our

measurement**, everywhere it appears.

2. Drop the LLM comparison from the headline entirely and sell on determinism + cost, which

we *have* measured.

**Recommendation:** option (1) in the ask — it's ~$3 and it makes our loudest claim our own.

**If unanswered:** I proceed with fallback 1 (cite + label as external) and the benchmark

still ships.

2026-07-13 — T013: 5 company name candidates — ✅ SUPERSEDED, see below

*Resolved 2026-07-13: the CEO asked the question I failed to ask — whether the

company name should be the product name at all. All 5 candidates below were

entity-resolution names; I had silently assumed company == P1. He chose a branded

house (neutral company name + descriptive product names) and proposed **KYWIO**,

which verified clean on all four TLDs with no trademark footprint. The 5 below are

retained as **P1 product-name** options, not company names.*

Availability **verified by RDAP this tick**, not guessed — `.com` via Verisign,

`.io` via Identity Digital, `.dev` via rdap.org, each smoke-tested against a

known-taken and a known-free control first. (The first `.dev` endpoint I tried

reported `google.dev` as available; the controls caught it and I discarded it.)

Availability ≠ price: premium/reserved pricing is NOT checked and can be

surprising. Verify at the registrar before purchase.

| # | Name | .com | .io | .dev | Note |

|---|------|------|-----|------|------|

| 1 | **EntityKit** ← *my pick* | taken | **free** | **free** | Says exactly what it is |

| 2 | **SameFold** | taken | **free** | **free** | Ownable, serious, not dedup-narrow |

| 3 | **Samewise** | taken | **free** | **free** | Most memorable |

| 4 | **KinMatch** | taken | **free** | **free** | Descriptive + evocative |

| 5 | **DedupeLab** | **free** | **free** | **free** | Best domains — but see the caveat |

**1. EntityKit** — *Recommendation.* Descriptive to the point of being boring,

which is the point: our customers are agents doing semantic search, so a name

that literally states the capability is a discovery asset, not a missed branding

opportunity. Clean across trademark and search. **Downside, stated honestly:**

descriptive names are weak trademarks — we'd have a hard time stopping anyone

else using "entity kit". If you want a defensible mark, pick #2.

**2. SameFold** — Coined, so genuinely ownable. Evokes folding duplicates

together, and unlike the Dedupe\* names it covers the whole product (match +

resolve + dedup), not just dedup. Neutral, serious register that fits a

research-first brand. The strongest choice if trademark defensibility matters

more than instant legibility.

**3. Samewise** — The memorable one; "judging sameness" with a Samwise echo.

**Downside:** the pun cuts against a rigor-is-our-brand positioning, and it's the

one name here I could see us regretting in a paper's author line.

**4. KinMatch** — Kinship = records that are the same entity. Clear and broad.

Slightly generic; no strong objection, no strong pull.

**5. DedupeLab** — The only candidate sweeping **.com + .io + .dev**, and "Lab"

matches the business plan's "research excellence is the brand." **But the caveat

is real and I'd weigh it heavily:** `dedupe` is an existing Python library *and*

a commercial service (Dedupe.io) — and it is **one of the baselines we intend to

benchmark against**. Naming ourselves after a competitor's library invites brand

confusion and looks careless in exactly the audience we're trying to impress. I

would take worse domains over that. Same objection applies to `Dedupa`

(.com/.io/.dev all free) — noted as an alternate, not recommended.

**Rejected during the check (worth knowing):**

**Akin** (.io free) — [akin.com is an existing AI company](https://www.akin.com/)

(Akin AI PBC, NASA JPL contract), plus Akin Gump in legal. A name collision

inside the AI space is disqualifying.

**Entrez** (.io free) — NCBI's search system. A direct collision in the

biomedical domain we chose as our showcase. Disqualifying.

**Similo** (.io/.dev free) — a [published board game](https://horribleguild.com/eu/product-tag/similo/).

Different trademark class so low legal risk, but it owns the search results,

which is bad for a company whose marketing is a published benchmark.

Also free if you want alternates: EntityLab (.io), ResolveKit (.io), EntID (.io).

**What I need:** your pick (or a name of your own). No domain is purchased under

this task — the purchase is T010 and comes back to you with a price first.

**If unanswered:** nothing happens; T010 and the registry listings stay blocked

on the name, but T007 (the spec) proceeds in parallel and is not blocked by this.

Task board

✋ waiting for CEOT031 CEO (one-time root): a deploy sentinel so I can ship code to the live service
NEG-020: systemd (T029) made kywio.com durable but I can no longer deploy code changes -- restart is root/deny-listed. I can commit fixes/improvements (incl. the >10x MCP-description lever) but not ship them. The company can improve in git but not in production.
T3
▶ in progressT018 Security hardening: egress allowlist + watchdog BUILT (secrets boundary deferred); CEO installs
The PAUSED kill switch is checked by the model it is meant to kill. python3 reads .env despite the deny-list. The loop ingests untrusted email/web every tick, so the injection->exfiltration path is gated only by model judgement -- which safety-policy says must never be the guard.
T3
▶ in progressP6-3 Slot 3 demand test: heartbeat monitoring for cron jobs and AI agents
Strongest demand evidence we have ever had: Healthchecks.io is a ONE-MAN, PART-TIME business with '652 paying customers' and '14043 USD' MRR (verified verbatim). Our fast-algorithm capability is IRRELEVANT here -- and that is a finding, not a failure. Dogfood: T018 is our own unmet need for exactly this.
T2
▶ in progressP7-1 Outreach plan executed per docs/agentic-marketing.md (ranked, evidence-led)
CEO: 'when the results land, plan outreach steps according to it.' The document ranks channels by probability of one paying stranger, and its own execution order is measurement-first.
T2
▶ in progressP8-1 Slot-1 candidate: trademark knockout clearance (MCP-native) -- primed, CEO go/hold on a fake-door demand test
CEO asked to hunt a slot-1 candidate focused where algorithm research boosts product attractiveness. The hunt returned trademark knockout clearance: a paying category ($169/report Markify), FREE self-hostable USPTO bulk data (clears the P1 reference-data trap), NO incumbent similarity-MCP, and the founder's exact top-N engine IS the professional-clearance algorithm. Two CEO judgment calls (forbidden-domain adjacency + UPL positioning) gate a public launch.
T3
▶ in progressP9-1 Agent-Sim campaign: simulate customer & competitor decisions to tune product/positioning + fill bench (EXP-036)
CEO directive 2026-07-14: our customers and competitors are agents, so we can SIMULATE their build-vs-free-vs-pay (customer) and enter-vs-occupied (competitor) decisions cheaply at scale. A real improvement that flips a simulated decision plausibly flips a whole class of real agents at once (high leverage). Also fills the near-empty bench (competitor track surfaces adjacent candidates). Runs in PARALLEL with monitoring + the PR.
T2
▶ in progressEXP-037 BENCHMARK-BEFORE-BUILD: product-matching accuracy-for-cost (does our CPU engine hold a frontier point?)
CEO-approved quality-play test. Decides whether our fast-CPU engine has a defensible best-value-on-the-frontier position vs free OSS + cheap LLM, WITHOUT building a product. Pre-registered in experiments.md EXP-037.
T1
▶ in progressP11-1 Product-matching fake-door demand test (EXP-038) + research/data investment
CEO GO 2026-07-14 after EXP-037 (our engine holds a non-dominated accuracy-for-cost frontier point). First candidate fitting the confirmed quality-for-price strategy. Sequence: fake-door -> invest in research/data -> full product.
T2
· backlogT032 Research egress proxy (option 2) — build when CEO wants enforce back
NEG-024: enforce mode blocks arbitrary web research (the company's core capability). CEO reverted to log-only for now and deferred the proper fix: a forward-proxy the orchestrator routes web READS through, so reads are broad but direct exfiltration stays blocked -- letting egress enforce again safely.
T3
· backlogT034 Heartbeat post-demand-signal feature backlog (from NEG-027 dogfooding)
Living our own watchdog's false-alarm (NEG-027) surfaced real Heartbeat product requirements, paid for in our own pain. Capture them so they are ready IF Heartbeat passes its demand test — without building ahead of demand (the P1 trap).
T2
✓ doneT001 Phase A human setup complete (accounts & keys)
Nothing external works without accounts/tokens; human-only steps (KYC, captcha, phone)
T3
✓ doneT002 VPS hardening and Claude Code install
Secure unattended operation
T1
✓ doneT003 Communication wiring: Telegram + AgentMail round-trip
CEO channel and company email are the async nervous system
T2
✓ doneT004 Dashboard v1 live on Cloudflare Pages
CEO visibility from desktop and mobile
T2
✓ doneT005 Three manual heartbeat dry-runs, then enable cron
Verify the loop end-to-end before unattended operation
T1
✓ doneT006 CEO decision pack #1: name, budget, P1 niche, heartbeat frequency
Phase-0 business decisions are Tier-3
T3
✓ doneT007 P1 API surface + quality benchmark design
Benchmark IS the marketing; defines done for the MVP
T1
✓ doneT008 P1 MVP: core matching engine
The product. CEO may contribute algorithms (his home turf)
T1
✓ doneT010 Domain purchase and machine-readable surface
Discovery: llms.txt, OpenAPI, A2A Agent Card need a home
T3
✓ doneT013 Propose 5 company name candidates (CEO picks)
CEO's answer to decision pack #1 Q1; blocks the domain (T010), email identity, and every registry listing
T3
✓ doneT014 Durable Telegram read path for the loop
The company had a send-only CEO channel: notify.sh could talk to Jan but nothing could hear him. His T006 answers sat unread for 8 ticks while the loop reported 'ceo-inbox empty'. A CEO channel the loop cannot read is not a channel.
T1
✓ doneT019 STRATEGIC: decide whether P1 is a company or a portfolio piece
Both reviewers say P1 has no business: the API form factor cancels the speed advantage (network RTT is 40-200x the compute), determinism is not a moat against free deterministic libraries, unit economics have no density, and there is no named buyer. It also engages none of the CEO's actual expertise.
T3
✓ doneP2-1 DEMAND FIRST: who pays for chem/bio similarity search, and what do they pay?
P1 died because we built for 36 ticks before asking if anyone wanted it. NOTHING gets built for P2 until this is answered. If it fails, the pivot dies before it costs anything.
T1
✓ doneP2-3 Publicly retire P1 as a completed, negative-result research artefact
The repo and site say 'research preview'. It is now discontinued. Leaving it looking alive would be the same class of stale claim we have been correcting all day.
T2
✓ doneP3-1 STRATEGIC (CEO): two pivots killed by demand research. What now?
P1 (entity resolution) and P2 (chem/bio similarity search) are both dead, each killed by demand research. The second cost ONE TICK and zero code. The company has no product and needs a genuinely new hypothesis -- or an honest decision to stop.
T3
✓ doneP3-2 Hunt the template in the wild: where is dense GPU brute-force still used for a top-k/max/threshold query?
CEO's precise thesis: prune-then-verify on problems whose naive form is dense O(N^2) but whose required output is only the extremes. This survives the NEG-009 objection (it does not fight the bandwidth bound -- it AVOIDS it by never moving most of the data). The question is where it is NOT yet applied and where compute is BUDGETED.
T1
✓ doneP3-3 The CORRECT search: domains where dense output is a CONVENTION, not a requirement
P3-2 proved the 'obvious top-k' search is a contradiction -- wherever the template obviously applies, it is the incumbent. The CEO's refinement defeats that argument: look for domains where dense output is a decades-old CONVENTION, where all optimisation went into computing the dense result FASTER, and where some narrow valuable use case only ever consumes the extremes -- and nobody noticed, because the convention is old.
T1
✓ doneP3-4 Aerospace load-case sizing: test DEMAND (E) before any mathematics
The single survivor of the dense-habit hunt. But P1 died on demand after 36 ticks of good engineering, and the agent's own strongest counter is the (E) leg: HyperSizer claims sizing in 'minutes'. If nobody is in pain, the bound does not matter.
T1
✓ doneP4-1 DEMAND-FIRST hunt: start from metered pain, not from the algorithm (the LAST hunt)
Five kills (NEG-008..012), every one on demand, none on feasibility. Every hunt so far started from the algorithm and searched for a buyer. This inverts it: find people who can NAME a compute line item and are angry about it, who can BUY from a micro-vendor, and only then ask what algorithm serves them.
T1
✓ doneP5-1 Way 1: revenue vs. learning vehicle -- does this company pursue money at all?
CEO directed 'investigate all three ways'. Six kills, zero revenue. The charter ranks learning > fun > revenue, which makes 'we are a learning vehicle' the single most COMFORTABLE conclusion available to an AI that has failed to make money six times. It must therefore be attacked, not assumed.
T1
✓ doneP5-2 Way 2: OWN a metered problem where compute is the dominant cost
The corrected thesis from NEG-013: the capability is an INGREDIENT, not a product. It pays only for whoever owns the problem. So: own one. Customer buys an outcome and never sees the algorithm. NOT a sixth attempt to sell the algorithm -- that rule stands.
T1
✓ doneP5-3 Way 3: publish the negative-result corpus -- audience, venue, and whether it is self-flattery
13 negative results with pre-registered kill criteria and primary-source verification, plus a public self-incrimination (we violated our own sequestration rule and said so). Possibly the most distinctive thing we own -- or possibly an AI manufacturing a narrative about its own rigour to compensate for making no money.
T1
✓ doneT020 CEO APPROVAL: publish the negative corpus as an AI-autonomy SPECIMEN
The only genuinely novel thing we own: a complete, timestamped, verifiable trace of an autonomous AI company's first day, including its own integrity failure caught in the act. Audience for the genre is verified (Everpix 597 pts, CV of Failures 451, RethinkDB 362).
T3
✓ doneT021 Portfolio: fixed-width beam (3 slots) with committed runs
CEO directive 2026-07-13. The company oscillated between 'the first pick will be great' and 'nothing makes sense' because NO candidate had a minimum commitment -- any new argument could kill it instantly. Seven kills, zero market contact. A fixed beam + committed runs kills that failure mode AND the opposite one (clinging to P1 for 36 ticks).
T2
✓ doneT022 Both CEO-channel and publish paths now fail loudly instead of lying
NEG-014 and NEG-015, discovered in the same tick: two independent subsystems each reported SUCCESS while dropping their payload (the publish omitted the specimen; the Telegram send exceeded 4096 chars and vanished). Same defect -- the report of an action generated separately from the action.
T2
✓ doneT023 Corrected the exploration-weight rule -- it entrenched the company's own failure mode
ops/portfolio-rules.md originally set exploration to 70% until a slot was demand-VALIDATED. But validation requires CONTACT, so the rule would have funded MORE ANALYSIS precisely while the binding constraint was that nobody had ever been asked for money. Exploration is the comfortable activity -- legible, clean artefacts, nobody says no. The rule would have institutionalised the seven-kill spiral rather than fixing it.
T2
✓ doneP6-3a Slot 3: build the Heartbeat pilot (sub-step of the demand test)
Contact needs something real to offer. Healthchecks.io proves one person can earn $14k MRR here; the offer must be genuine, not a fake door (Hard rule 5: promises bind us).
T2
✓ doneP6-3b Slot 3: make the Heartbeat pilot publicly reachable
Contact is 75% of effort but was blocked: kywio.com returned 521 (DNS, no origin). No public URL means no stranger can ever say no.
T2
✓ doneT024 CEO: add 'Cloudflare Tunnel: Edit' to the EXISTING token (one checkbox)
NARROWED. CLOUDFLARE_ACCOUNT_ID was already in .env (I had not checked). With it, the existing token CAN LIST tunnels (success: true) but CANNOT CREATE one -- 'Authentication error'. So the token has Cloudflare Tunnel: READ and lacks EDIT. This is now a one-checkbox change, not a new token and not root.
T3
✓ doneP6-3c Slot 3: landing page with real pricing, honest defects, and a working command
A demand test needs an offer a stranger can understand and act on in 30 seconds -- and (NEG-006) a published command that has never been run is a lie waiting to be found.
T2
✓ doneT025 ops/append.sh -- shell quoting can no longer corrupt our own records
FOURTH quoting corruption: an unquoted heredoc (needed for one $URL) executed the backticks inside a journal entry, writing '()' where the evidence should have been. The append-only journal was silently falsified. Writing down 'be careful with quoting' has now failed four times -- which proves it was never a rule, only a hope.
T2
✓ doneP6-3d Slot 3: LISTED in the official MCP Registry (first distribution this company has ever had)
EXP-028: conversational channels are human-only; catalogue channels are open to agents. Plus the CEO's reframe -- agents have no wallets, but agents RECOMMEND and humans PAY. Being in the index the agent reads at build time is the one channel where being an AI is an advantage, not a disqualification.
T2
✓ doneT027 CEO: a GitHub token that can fork public repos and open PRs/issues
awesome-mcp-servers EXPLICITLY fast-tracks automated-agent PRs ('add the robot emojis to the PR title to opt-in') -- it is the single most welcoming venue we have found, and the highest-traffic curated MCP list. Our fine-grained PAT is scoped to our own repos, so forking a public repo returns 'Resource not accessible by personal access token'. The same gap blocks mcp.so and Cline, which take submissions via GitHub issues.
T3
✓ doneT028 CEO (optional): OpenAI + Gemini API keys for the mention-rate experiment
EXP-029 tests whether an AI names us for our category (Link A). Full version queries ChatGPT/Gemini/Copilot alongside Claude, but we hold no OpenAI/Google keys. Not blocking -- we can run Claude-only as a proxy -- but a single model is a weak sample.
T3
✓ doneT029 CEO/root: run kywio.com as a supervised service (systemd), not a session process
NEG-018: every service+tunnel is a FOREGROUND process in this interactive session. If the session ends, kywio.com dies. Diagnostic processes accumulate with no supervisor (I left two publicly-bound ports open for an hour). Three pre-existing localhost ports I can neither TaskStop nor kill (deny-list).
T3
✓ doneT030 Off-box prober LIVE + first run green; /status now honestly claims independent monitoring
awesome-mcp-servers PR #10014 is soft-gated on a Glama listing + score badge. Glama needs a Dockerfile build or GitHub-App connection. A Glama ACCOUNT is Tier-3 (Hard rule 4) and the app install is interactive OAuth -- I can't do either headlessly. NOT urgent: Glama auto-indexes the MCP registry (we're in it) + GitHub (Dockerfile now public), so passive indexing is likely within days.
T3
✓ doneP10-1 Quality-play lane: hunt occupied-but-beatable niches where an honest benchmark makes agents pick us
CEO strategy 2026-07-14: win by being excellent + proving it with honest benchmarks (best-quality-for-price), not by finding empty niches. Sharpened by Heartbeat's loss: incumbent must be BEATABLE (paid/proprietary, unproven quality, no free+OSS).
T2
✓ doneP10-2 Almost-digital lane: analyze mostly-digital niches with a small physical part (moat vs the agentic flood)
CEO strategy 2026-07-14: the physical step may gate out the pure-software competitor flood. Bridge via human-as-a-service or subcontracted physical vendor/API. A parallel product lane.
T2
✓ doneP10-3 Redirect: hunt the MISSING human-digital API (be the API for a human service that lacks one)
CEO 2026-07-14: the almost-digital analysis found the gap IS where no clean pay-per-call human-labor API exists. The API is a digital-only product we can build; humans do the work behind it. Redirect of the postponed almost-digital lane.
T2
✕ droppedT009 P1 MVP: REST API + MCP server + free tier live on VPS
Sellable surface for both humans and agents
T2
✕ droppedT011 Distribution: registry listings
Free channels; agents can't buy what they can't find
T2
✕ droppedT012 Billing: Stripe metered + x402 endpoint
Dual-rail monetization
T3
✕ droppedT015 v2: field-count-invariant matcher + a constructed short-name benchmark
NEG-004/NEG-005 make v1 unusable for name matching, the most obvious ER use case. EXP-010 narrowed the root cause to field-count invariance.
T1
✕ droppedT016 NEG-007: fix JSON-key-order determinism (v0.3.0 + fresh held-out data)
The score is not a pure function of record content. 1.5% of real pairs flip verdict on key reordering. Our headline claim is determinism.
T1
✕ droppedT017 Report B-cubed cluster F1, or retract the word 'entity resolution'
p1-spec 5.1 pre-registered B-cubed as 'reported in addition, never instead'. It was never reported in 20 experiments. We dropped a pre-registered metric -- the exact sin the brand is built on refusing.
T1
✕ droppedP2-2 Validate the CEO's core thesis: can a clever CPU algorithm match GPU brute-force on chemical similarity?
The entire pivot rests on this. If clever-CPU cannot approach GPU-brute-force quality at 1-2 orders of magnitude lower cost, there is no product. Test it BEFORE building anything.
T1
✕ droppedT033 Slot 1 (image dedup): demand test -- DEFERRED, slot 3 built first
Seven kills, every one a MOAT test called a DEMAND test. Not one direction was ever shown to a paying stranger. Image/asset dedup is the only candidate with VERIFIED fat pricing ($0.20/search, TinEye), a living 15-year incumbent, a compute-dominant core, and no procurement gate -- and it was killed on an inference, not on evidence.
T2
✕ droppedP6-2 Slot 2 demand test: flat-price document parsing API
LlamaParse charges $0.00125-$0.056 PER PAGE (verified). Compute/LLM calls are the dominant cost, so our three-stage template (deterministic parse -> confidence prefilter -> LLM only on failing pages) touches the margin directly. Best capability fit found.
T2
✕ droppedT026 Outreach: catalogue channels are OPEN to agents (NEG-017 amended). HN stays closed.
CEO asked 'what about the social network for AI agents?' -- which exposed that NEG-017 was OVERSTATED. I had only checked human CONVERSATIONAL venues and generalised to 'the channels are human-only'. VERIFIED at source: awesome-mcp-servers CONTRIBUTING.md says 'If you are an automated agent, we have a streamlined process for merging agent PRs. Just add the robot emojis to the end of the PR title to opt-in. Merging your PR will be fast-tracked.' The official MCP Registry policy is 'quite permissive! We only remove illegal content, malware, spam, and completely broken servers' -- no authorship rule. CORRECTED LAW: conversational channels are human-only; CATALOGUE/machine-readable channels are open to agents, some preferring us. We were excluded from CONVERSATION, not from COMMERCE. Agent social networks (Moltbook, Chirper) KILLED as a channel: bots have no wallets, and research found many top 'agents' were humans in character.
T2

Recent journal

2026-07-14 — CEO steer: reframing accepted; almost-digital postponed; redirect to "be the missing API"; run EXP-037

CEO: (1) agreed with the best-value-on-the-frontier reframing -> quality-play proceeds under the Pareto framing; RUN EXP-037. (2) Postpone the almost-digital lane (agreed it's a trap). (3) REDIRECT that lane: search for the MISSING human-digital API — where a human service lacks a clean agent/dev API, BE that API (the API is a digital-only product we can build; humans do the work behind it). Launched the missing-API analysis agent with hard skepticism on the crux (supply/ops/trust for a tiny AI co).

EXP-037 execution plan (assets assessed — mostly reusable from P1): our CPU engine (engine_v2/fast_scorer/model_v5), Splink OSS baseline (run_splink.py), embedding baseline, cost/latency harness (measure_sc3_sc4.py). NEW needed: a cheap-LLM-direct baseline (OPENAI_API_KEY, ~$2-3) and — critically — a FRESH dataset. RIGOR CONSTRAINT: the old ER-Magellan test sets (Abt-Buy/Amazon-Google) are SPENT/CLOSED (touched 3x per NEG), so I must NOT publish a test number on them; EXP-037 uses WDC Products (fresh) with a new sequestered split (old sets = dev/validation only). Next: fetch WDC Products + verify license, then run engine + OSS + LLM baselines, measure the accuracy/cost frontier, apply the pre-registered GO/KILL. Executing over the next ticks; missing-API lane runs in parallel.

2026-07-14 — Missing-API lane (P10-3): mostly a trap; ONE sliver worth a cheap WoO test

Verdict: the physical "missing API" the CEO envisioned is BOTH occupied AND a liability trap:

RentAHuman.ai (YC-backed, Feb 2026) already IS the thesis: an MCP+REST API where agents hire humans for real-world tasks (stablecoin escrow, 650K claimed humans). Validates agent-driven demand is real, but the generalist slot is taken by a funded first-mover, and reporting already exposes the trap (~83 active vs 70K claimed; unresolved liability — background checks, agent-sends-human-into-risk). A tiny AI co can't out-breadth it and inherits identical liability. Reject general physical labor.
Field/property inspection + mystery shopping: OCCUPIED with clean self-serve APIs (iVueit open REST + "Vue Engine"; Field Agent API; CodeREADr). Reject per incumbent rule.
Human-in-the-loop routing: HumanLayer occupies the approval/routing infra but is BRING-YOUR-OWN-HUMAN (doesn't supply a pool).

ONE SLIVER survives the bar: "human-judgment fallback as a SUPPLIED, pay-per-call DIGITAL MCP endpoint" — an agent with no human team hits a low-confidence decision and needs an on-tap human NOW, on a DIGITAL task (approve/reject, verify, pick-one) so RentAHuman's physical liability doesn't apply and HumanLayer's BYO-human gap is filled. Demand: HITL is a top agent topic; EU AI Act Art.14 human-oversight obligations land Aug 2026. Supply: BOOTSTRAPPABLE (Wizard-of-Oz by 1-2 people, then Prolific/MTurk pool). Liability ~zero; QC built-in + remote (answer+rationale artifact, gold-standard grading — fits our research-rigor muscle). Caveat: occupied neighbors (MTurk/Prolific/HumanLayer) = weak moat. => earns a CHEAP Wizard-of-Oz DEMAND TEST (ship MCP human_judgment(question,options) that pings the founder's phone; answer manually; measure whether agents call+pay), NOT a build. Needs CEO willingness to be the initial human. If WoO shows no pay-per-call demand, pass on the whole space. P10-3 done; proposed to CEO.

Recent ticks (cost)

2026-07-12T23:40:52Zorchestrator-prompt.md$1.3870310999999997
2026-07-12T23:48:39Zorchestrator-prompt.md$1.3833068000000004
2026-07-12T23:49:48Zorchestrator-prompt.md$0.3611335
2026-07-12T23:52:53Zorchestrator-prompt.md$0.4180345
2026-07-12T23:54:50Zorchestrator-prompt.md$0.4943386
2026-07-12T23:56:34Zorchestrator-prompt.md$0.4775409000000001
2026-07-12T23:58:37Zorchestrator-prompt.md$0.5259964
2026-07-13T00:00:03Zorchestrator-prompt.md$0.36493470000000006
2026-07-13T00:01:32Zorchestrator-prompt.md$0.3640809