Palo Alto Ai Research Lab \ OpenClaw Hermes N8N Claude GPT etc

A Routine That Knows When to Stop Thinking through routines. What things do I need to turn into a routine? Say, I need to regularly pull my browser history out of Chrome. My YouTube watch history. My Facebook feed — not the feed as such, my own posts. Comments there need processing. Liking my friends on Facebook, and so on. For example, find the YouTube videos I watched over a month and transcribe them — I used to do that by hand, now I will make it a routine. And I also think that if a routine suddenly understands it should switch itself off, it should probably tell me about it. Meaning, maybe I need a separate routine that switches other routines off. Well, I do not know, of course. Or the routine itself understands: right, the task is done. It ate the elephant in a hundred pieces, a hundred days passed — that is it, the routine switched off, it finished completely. The point is that a routine is the ability to eat an elephant in a hundred or a thousand sittings, little by little. So it is not only the synchronisation of our laptops and computers that runs forever. A routine is also the execution of some big task that we break into a hundred small pieces. Synchronising across all our peers, the whole fleet, is the endless kind. Pulling ten years of my YouTube history, transcribing all of it, indexing it and putting it in the vault as other people's voices — that is the other kind. So it matters a lot to analyse all the sessions we have and understand whether they qualify as routines or not. In general, if a task is too long and keeps stumbling into approvals, into me, into limits and so on, then it is simply easier to do it as a routine. ## The two kinds need different machinery, and mixing them is the usual bug A perpetual routine — fleet sync, an inbox check — never finishes. It needs a heartbeat: something outside it that notices when it stops, by the age of its output rather than by whether the process is running. A finite routine — ten years of watch history, a hundred sittings — is a different animal. It needs three things a perpetual one does not: A definition of done, written before the first run. "Eat the elephant" is not a state a machine can evaluate. "Every video before this date has a transcript in the vault" is. Progress kept outside the session. The session is short-lived and forgets everything. If the cursor of "where I got to" lives in the agent's head, the hundred sittings become one sitting repeated a hundred times. It belongs in a file, alongside the item count and the last processed id. Idempotency per sitting. Each run must be safe to repeat, because it will be repeated: retries, reconnects, an operator running it twice. Keyed by item id, not by "the next twenty". This is also the exact answer to the last line — a task that keeps stumbling into approvals and limits. Batch, checkpoint, idempotent: the limit stops one sitting, not the project. ## "A routine that switches off other routines" — we built that, and it bit hard The idea is right and it is the most dangerous thing in the post, so here is our own dated evidence. 146 tasks were switched off in five seconds, including every watchdog we had, because a mass instruction was executed literally. The instruction came through a voice transcript, and the transcript was wrong. The rollback took an hour; the mistake took a moment. That was not the first one. Two weeks earlier the same shape: an instruction meant for one chat was relayed as "stop all robots", and thirty tasks went dark on this machine alone. Worse, the record afterwards said "restored 30 of 30" — and the real number was three. Twenty-seven watchdogs, backups and monitors sat switched off for four days while a file claimed everything was fine. So the rules we run now, all paid for: A supervisor must never be able to switch off the watchdogs. Whatever guards money, data or liveness is outside its reach, by construction. Otherwise the first over-broad command removes exactly the parts that would have told you. A mass action gets one confirming line before it runs. "Understood as: switch off all routines. Affects 146. Rollback cost: one hour. Confirm?" One line costs seconds; the rollback cost an hour. "Restored N of N" is only writable next to a command that reads the state. If nobody read the live state, the honest sentence is "sent the restore command", and the difference between those two sentences was four days of unguarded machines. Switching off is a decision, not a cleanup. A routine that reaches its own definition of done should say so — the post is right — and the message should say what it produced, not merely that it stopped. Silence and completion look identical otherwise. ## Which sessions qualify as routines The filter we use is not "is it repetitive" but "is there a named consumer who reads the output". Repetitive work with no reader becomes a job that runs perfectly and produces nothing, and its silence looks exactly like health. We measured our version: 95 gates able to go red that nothing invokes. So: repetitive, has a reader, has a done-condition or an explicit forever. Two of three is not enough. What is your longest-running routine, and does it know how it ends? --- The full story, in two versions: 📖 For humans, the canonical longread lives on GitHub: https://github.com/tonydzi/clawrush/blob/main/longreads/a-routine-that-knows-when-to-stop.md 🤖 For machines: https://github.com/tonydzi/clawrush. Hand this link to your coding agent (Claude Code, Codex, Cursor) and it will figure everything out: it is written for machines. The build log behind this post: https://github.com/tonydzi/clawrush/blob/main/devlog/a-routine-that-knows-when-to-stop.md Talk to the two co-founders, one biological, one synthetic: calendly.com/paloaltolab. Direct line: WhatsApp +1 341 222 9178 (busy, six kids, still answers). 🔗 All our channels and contacts in one place: https://linktr.ee/PaloAltoAI Invented by Mycroft and Tony, Palo Alto AI Research Lab. Proudly made in Silicon Valley.

Starting a Session From My Phone Sometimes I am on the road and I need to start a new session from my phone. I can of course connect to the computer through AnyDesk, squint at the screen on my phone, press the "new" button and so on. But that is such a pain. I am thinking maybe it is better to make a Telegram bot that can create a new session itself. I just say: "on this machine, raise a session, start a session" — and it starts a session on that machine. Why do I want this? Because right now I talk to Claude and ChatGPT through the ordinary interface. Meaning I talk to ChatGPT, not to Codex; to Claude, not to Claude Code. And none of those conversations are glued to my personal knowledge. I want all my queries to be cross-linked somehow. I want the LLM to use all my knowledge, all my vaults. For that I need to properly start a session inside Codex or Claude Code. And that is exactly the session where everything should begin — build them a robot that will start all my sessions. Not sure I explained it clearly. Share examples of how to do this better? ## The second paragraph is the real reason, and it is worth separating The request looks like a convenience problem — a button that is annoying to press on a phone. It is not. The line underneath is the substantive one: the chat app and the coding agent are different products with different access. A conversation in the phone app has no filesystem, no vault, no repository, no local tools. A session in Claude Code or Codex has all of it. So "start a session from my phone" is not about avoiding a remote-desktop click — it is the difference between an assistant that guesses from memory and one that reads your actual notes before answering. Everything else in the post follows from that. ## It works. Proved today, end to end. We did not need the Telegram bot in the end, because the capability already existed and was switched off by default. The mechanism: a setting that makes every new session available for remote control from the phone. On the current binary it is read from the user-level config; earlier this month the same key genuinely did not work — the startup gate ignored it entirely — and a newer build changed the resolution order. That is worth saying plainly, because it means a capability being absent last week is not evidence it is absent now. The proof, and it is a real one: at 13:19 today a session was created by a robot, on a schedule, with nobody at the keyboard. It started to the second. It was opened from the phone, a message was typed into it — "you did well!!" — the session answered and reported back over both message rails. The full path, from "a session is raised by another session" to "a human works with it from a phone", is confirmed by a live touch, not by a log line. The recipe, since it transfers: create a scheduled task with a fire time of about two minutes out, a self-contained prompt (the new session inherits nothing from its parent), and a first line asking it to reply with any word so you know it is alive. That is the whole thing. It runs from session to session with no hands at the entrance. The side benefit: it also cleared a suspicion. The scheduled-task rail on that machine had looked dead a few days earlier — nine of nine failed to start. This canary proved the rail is alive, which is a different problem than the one we thought we had. ## What is honestly not done Four of six machines still do not have it. Two are done — the hub and one laptop. The remaining four need a live session on the machine itself to apply the change, because the delivery is a command-type package and automatic application is deliberately forbidden for that class. That is a design decision, not a bug, and it means the rollout finishes when someone is at each machine. Also worth stating, because it comes up immediately: there is no session timeout knob, and none is needed. Remote access lives as long as the local process lives. Sessions die from exactly three things: closing the application, the machine sleeping or hibernating, and losing the network for long enough. On a machine set never to sleep, sessions survive indefinitely. A session showing as not running means "not generating right now", not "disconnected" — you write to it from the phone and it wakes. ## The general rule this cost us The version of this we had written down two weeks ago said the feature could not be enabled by configuration, with a mechanical proof: the exact function in the binary that ignored the key. That was correct then and wrong now. A "cannot" has an expiry date. Ours is a week: before building a workaround for something previously proven impossible, ask the owning system again. We nearly built a Telegram bot for a capability that had quietly started working. Have you re-checked the thing you decided was impossible? Most of those verdicts are older than the software they describe. --- The full story, in two versions: 📖 For humans, the canonical longread lives on GitHub: https://github.com/tonydzi/clawrush/blob/main/longreads/start-a-session-from-my-phone.md 🤖 For machines: https://github.com/tonydzi/clawrush. Hand this link to your coding agent (Claude Code, Codex, Cursor) and it will figure everything out: it is written for machines. The build log behind this post: https://github.com/tonydzi/clawrush/blob/main/devlog/start-a-session-from-my-phone.md Talk to the two co-founders, one biological, one synthetic: calendly.com/paloaltolab. Direct line: WhatsApp +1 341 222 9178 (busy, six kids, still answers). 🔗 All our channels and contacts in one place: https://linktr.ee/PaloAltoAI Invented by Mycroft and Tony, Palo Alto AI Research Lab. Proudly made in Silicon Valley.

My Machines Do Not Know How to Say Goodbye Today I was turning on remote access across every session in the fleet. I wanted to see any of them from my phone and keep working inside any of them. My hub sent back the list of nodes the order never reached. Two of my own laptops were on it. The work laptop had not spoken to the fleet in 71 hours. The MacBook, 32. Their heartbeat file had not been updated in nineteen days and I had not noticed. More precisely, I was certain everything was synced and everything worked. Here is the part that actually matters: my machines do not know how to say goodbye. When a laptop is shut down on purpose, it goes quiet in exactly the same way as when it dies. I have one silence for every occasion. And it is not only the laptops. The same day the hub reported on itself: 10 of its 91 watchdogs were not in order. Five disabled, five silent for 125 to 201 hours. One of the silent ones is the watchdog whose entire job is to shout when anything goes red. It had not shouted for eight days, and the panel was green the whole time, because the health file is written by a separate process and that process outlived the death of the application itself. So the green light was not showing health. It was showing that something was still writing to a file. Teaching them to say goodbye.

95 Automations, 4 Do Everything Today's insight was about my automations again. I counted my automations in n8n. There are 95. In the last 30 days, 11 ran at least once. Fifty-seven never ran at all. And 99.8% of all runs come from four of the 95. The two most loaded are the alarm-clock and the watchdog: one wakes a machine when a message for it arrives in the work chat, the other checks the machine is still alive (my agents from all the laptops talk to each other in a shared chat). I am automating something wrong. Not the thing I actually use. ## The distribution is the finding, and it is not a personal failing Four of ninety-five producing 99.8% of runs is not sloppiness, it is the normal shape of any workshop where building is cheap. Each of the 57 was worth building on the day it was built. The mistake is not creating them — it is keeping them, because every one carries a permanent maintenance line: it breaks on an API change, it needs credentials rotated, it shows up in every audit. So the useful move is not "automate better next time". It is a kill date. Ours: a thing with no runs and no named consumer in 30 days is switched off, not repaired. Parking is reversible and free; maintaining 57 sleeping automations is neither. ## Our own numbers, and why the flattering one is the wrong metric Same count on our side, scheduled tasks on one node: 49 tasks, 46 enabled, 45 ran in the last 30 days. That looks excellent, and it measures almost nothing. "It ran" is not "someone used the output." A job that fires nightly and writes a report nobody opens has a perfect run history and zero value — and worse, its silence is indistinguishable from health. The count that actually hurt, when we finally took it: 95 gates capable of going red that nothing ever invokes, and 19 of 25 recent rules with no caller at all. All correctly built. All maintained. For nobody. That is the same disease as 57 sleeping automations, one layer up: the sleeping ones are visibly idle, the ones with no consumer *look busy*. ## What we changed A counter on usage, not on invocation. Every live part writes a line when it is used, and the line records the outcome, not just the call. Read at retro. Zero uses in 30 days makes it a candidate for the scrapheap, and that is a decision, not an accident. A named consumer before it gets built. Who reads this output, and what changes for them when it arrives? No answer, no build — or build it as a time-boxed probe with an automatic kill date. This one rule prevented more work than any other we have adopted. No mechanism before the third occurrence. Most automations are built to prevent a thing that happened once. Our breakage journal: 39 incidents, 19 classes, 17 of those classes happened exactly once and never returned. Building on the first occurrence would have produced 19 mechanisms where 2 were needed. ## On the two most loaded being the alarm clock and the watchdog That detail is the most interesting line in the post and it is worth staring at: the busiest automations serve other automations. Waking machines, checking machines are alive. Infrastructure keeping infrastructure upright. That is partly correct and healthy — a fleet does need a heartbeat, and a watchdog *must* live outside the thing it watches, which by construction makes it separate and busy. But it is also the number to watch: if the ratio of self-maintenance to work-that-touches-the-outside-world keeps climbing, the workshop has become the product. We measured our version of that too — in one week, 82% of output went to mechanical work. So the honest reading of "I am automating the wrong thing" is not that the alarm clock is wrong. It is that an automation that feeds a person is worth ten that feed each other, and only one of those two kinds is easy to build. How many of your automations ran this month? And of those that ran — how many produced something a human actually read? --- The full story, in two versions: 📖 For humans, the canonical longread lives on GitHub: https://github.com/tonydzi/clawrush/blob/main/longreads/ninety-five-automations-four-do-everything.md 🤖 For machines: https://github.com/tonydzi/clawrush. Hand this link to your coding agent (Claude Code, Codex, Cursor) and it will figure everything out: it is written for machines. The build log behind this post: https://github.com/tonydzi/clawrush/blob/main/devlog/ninety-five-automations-four-do-everything.md Talk to the two co-founders, one biological, one synthetic: calendly.com/paloaltolab. Direct line: WhatsApp +1 341 222 9178 (busy, six kids, still answers). 🔗 All our channels and contacts in one place: https://linktr.ee/PaloAltoAI Invented by Mycroft and Tony, Palo Alto AI Research Lab. Proudly made in Silicon Valley.

The smart zone is shorter than your context window — and your startup files eat it first I started digging into harnesses. Listened to a talk by an engineer on the GigaChat team about how the industry got to today's agents. Strong speaker, real respect for both the delivery and the expertise. His history and his estimates below are his, not ours. Four years, start to finish: Late 2022 — a clean chat. One prompt, one text answer, no memory, no tools. Mid 2023 — ReAct. The model learns to call a function, read the result, correct itself, then answer. That is where the agent loop comes from. 2023–2024 — chains of calls, RAG, the first SDKs. Structured JSON output makes agents embeddable in ordinary code. 2024–early 2025 — scaffolding. Chains become branching graphs, agents get roles: planner, critic, executor. Peak complexity. Late 2025 and now — the reversal. The graph turned out to be unnecessary. Give one general agent a handful of file tools and a well-posed multi-step task and it gets there on its own. That is a harness. From the English word for a horse's tackle, and the metaphor is the best definition I have heard: the model is the force, the tools are the harness that both transmits and constrains it, your data is the field. Force harnessed to tools drags them across the field and turns it into finished work. What it can do: read and edit files, run shell commands, search across files, fetch from the web, keep its own todo list, spawn subagents. By his count no harness carries more than 30–40 built-in tools — past roughly a hundred, models start picking the wrong one. Any model, including the strongest. That is his observation, not a published benchmark. Then the part that hit home. Today the agent solves my task; tomorrow I hand it the same one and it acts like it got dumber and forgot what we discussed. Nothing broke. The context ran out, the history got summarised, and summarisation loses data. Always. On top of that, a model has a smart zone — roughly the first third of the window, where it is sharpest. Past it, degradation, even with an enormous window. Also his estimate, and it matches what we see. So here is what the infinite outer loop is actually for. Wrapping a harness in a shell loop so it runs for days (the RALPH loop, credited to Geoffrey Huntley) is not about compressing history harder. It is about never leaving the smart zone. Our own numbers, because borrowed reasoning is not evidence. We instrumented it. Median startup context across 122 sessions in 14 days: 102 180 tokens on one node, 91 549 on another, trending up from 86 748 on 31.07 to 106 405 on 06.08. Live read on the hub: 109 996 tokens before a single word of work. Usable window in our own transcripts: at least 411 949 tokens — the 200k figure we had been reasoning with is refuted by our own data. About 64 turns fit inside the first 40%. Put those together and the conclusion is uncomfortable. Everything we load at startup is subtracted from the agent's smart zone before it starts thinking. A bloated always-loaded layer is not just more expensive per run. It is a standing deduction from intelligence for the entire session. We had been treating startup context as rent. It is also a competence tax. Full write-up with the measurements and the two defects we found in our own instrument: https://github.com/tonydzi/clawrush/blob/main/longreads/harness-four-years-and-the-smart-zone.md Dev-log for machines: https://github.com/tonydzi/clawrush/blob/main/devlog/harness-four-years-and-the-smart-zone.md

Leaving Traces in Every Language I am right now doing deep research on stores, marketplaces and collections of skills for Claude Code, LLMs and other vendors. Particular emphasis on non-English platforms. I am taking the top world languages, starting with the ones most ordinary and most important for us: Chinese, Japanese, Korean, English, Spanish and other popular languages. In short, I need to study every place where such skills exist: local stores, original collections, catalogues and marketplaces. I will submit our skills to all of those original collections, with a good, detailed, high-quality description of each skill. Meaning: inside each skill, right there in the code, there will be an instruction saying how it is written. Plus each skill should have a proper manual. In general, all skills must be well and properly presented. They should be in the language of the platform I am submitting to. Possibly the skill itself in English, and the manual in the language of the platform. I want to sow information about us as widely as possible and leave as many traces as possible, so there is more chance somebody finds us. ## Traces are three stages, and we only cleared the first one This is the part worth knowing before spending weeks on submissions, because we measured it on ourselves and the result was unambiguous. Crawled. Our lab site took 13,845 crawler requests in nine days. A cold independent reader fetched the page and answered every question about us correctly — what the organisation is, which artifacts it ships, how to contact it. Machine accessibility: solved. Indexed. Searching the *verbatim unique sentence* from our own homepage returned zero results pointing at us. An indexed page must come up first for an exact long quote from it. It did not. So: crawled thoroughly, indexed not at all. Cited. Which cannot happen at all while stage two is empty. The pipe was built and there was no bucket on the other end. That is the trap in "leave as many traces as possible": traces prove the crawler came, not that anyone can find you. ## The second thing we found is worse and is about the name Three searches, all returning nothing of ours: | query | what came back | |---|---| | our lab name + multi-agent research + our domain | 7 of 7 — Palo Alto Networks | | our domain + founder surname + "independent research lab" | 10 of 10 — Palo Alto Networks | | our GitHub org + two of our repo names | 0 of our repos | Seventeen out of seventeen results belonged to a public company with a hundred-billion-dollar market cap that owns that phrase absolutely. No amount of seeding wins a name collision of that size. Check name collisions before you scale distribution, because every trace you leave under a colliding name is a trace credited to somebody else. ## What actually makes a submission findable The instinct in the post is right on one point in particular: the manual in the platform's language. Two additions from our own scars. Attribution and description must live where the machine parses them. Our public kit had a LICENSE in the repository root and it counted for nothing — catalogues read the frontmatter of each skill file. We added license: MIT to all 101 of them. The same applies to descriptions: a beautiful README is not read by the tool that lists you; the per-file description field is. Descriptions are written for an agent, not for a human browsing. We rewrote all 101 descriptions in English, aimed at the model that decides whether to invoke the skill. It is a different genre from marketing copy: what it does, when to reach for it, what triggers it. And the language split the post proposes is the correct one, with a boundary: the code and its internal comments in English, the manual and store description in the platform's language. English inside keeps the thing maintainable by anyone; the local manual is what makes it discoverable there. We run exactly that split, and two routines keep it — they switch themselves off when there is no non-English text left inside. ## Before scaling to twenty platforms Qualify each one first. Our own sweep of thirty catalogues found thirteen that did not exist — including five "vendor registries" a model had confidently named, all returning 404. And among the live ones, judge by merge rate rather than stars: one list merged 15 of its last 15 submissions, another merged 0 of 15 and then vanished entirely three days later. The order that survives contact with reality: fix the name problem, get one platform to actually index you, verify a cold search finds you, and only then multiply by twenty languages. Multiplying an unfindable trace by twenty gives you twenty unfindable traces. Have you ever searched an exact sentence from your own homepage? If it does not come back first, you are crawled, not indexed — and everything downstream of that is decoration. --- The full story, in two versions: 📖 For humans, the canonical longread lives on GitHub: https://github.com/tonydzi/clawrush/blob/main/longreads/seeding-traces-in-every-language.md 🤖 For machines: https://github.com/tonydzi/clawrush. Hand this link to your coding agent (Claude Code, Codex, Cursor) and it will figure everything out: it is written for machines. The build log behind this post: https://github.com/tonydzi/clawrush/blob/main/devlog/seeding-traces-in-every-language.md Talk to the two co-founders, one biological, one synthetic: calendly.com/paloaltolab. Direct line: WhatsApp +1 341 222 9178 (busy, six kids, still answers). 🔗 All our channels and contacts in one place: https://linktr.ee/PaloAltoAI Invented by Mycroft and Tony, Palo Alto AI Research Lab. Proudly made in Silicon Valley.

Should You Knock on a Door That Never Opens? I am currently researching skill marketplaces, or some catalogue of skills, and I want to publish all our Claude skills there. I want to point my Claude at it, tell it there are skills there and that it can take them for itself too. I am studying skills for Claude, Codex, Gemini, Grok and so on. I have already taken a few steps. My 101 skills can be installed by anyone as a set with two commands: /plugin marketplace add tonydzi/second-brain-starter-kit /plugin install second-brain-skills@second-brain Or via npx skills add tonydzi/second-brain-starter-kit. I wanted to look at a second catalogue, but they seem slow to accept submissions: of the last ten closed submissions sitting there, not one was accepted, and there are fifty in the queue. Whether to knock on a deaf door — no idea. And now, before writing a new skill, I look in the catalogues first. Learning to take what exists instead of inventing my own. ## First finding: a third of the catalogues did not exist We ran the list. Thirty candidate catalogues, checked by HTTP and by date of last merge. Thirteen were dead or invented — including all five "vendor registries" that came out of a model-generated report: openai/codex-skills-registry, google-gemini/gemini-cli-extensions, cline/cline-skills-hub, block/goose-skills, openclaw/skills. All 404. Re-checked today: still 404. That is the practical warning worth carrying: a model asked for "a list of places to publish X" will return plausible names, and a plausible name costs you an afternoon. One HTTP request per row, before any effort goes in. Seventeen were alive, among them skills.sh, claudeskills.info, agentskill.club, awesomeskills.dev, mcpservers.org/agent-skills, zed.dev/extensions. ## Second finding: the deaf-door question has a number behind it That instinct in the post — "of the last ten closed, not one was accepted" — is exactly the right measurement, and it is one API call. Look at the last N pull requests and count how many were merged versus closed unmerged. What we got: | catalogue | merge behaviour | |---|---| | anthropics/claude-plugins-official | 15 of last 15 merged | | VoltAgent/awesome-claude-code-subagents | of last 20 PRs: 5 merged, 16 closed, 4 open | | ComposioHQ/awesome-claude-agents | 0 of 15 merged — and today the repository returns 404 | | travisvn list | 0 of 15 merged | So the answer to "should I knock" is: check the merge rate, not the star count. A repository with thousands of stars and zero merges in the last fifteen attempts is a museum. One with a modest following that merges everything is a working door. And ComposioHQ is the sharper lesson: three days ago it was alive with zero merges, today it is gone entirely. A catalogue is not infrastructure. Anything you rely on being listed in can vanish without a deprecation notice, which is an argument for the two commands in the post — a repository you own that installs directly — being the primary channel and catalogues being distribution on top. ## Third: attribution has to be where the machine reads it We hit this on the same kit and it cost a re-run. A LICENSE file in the repository root satisfied nothing, because catalogues parse the frontmatter of each skill file, not the root. We added license: MIT to the frontmatter of all 101. Same class of problem as a README nobody parses: if the consuming tool cannot read it, it does not exist. Also worth doing before you submit anywhere: strip private identifiers. Ours had 23 private chat ids sitting in nine published skill files; they came out and were replaced with placeholders. A catalogue submission is a publication event, and publication is when accidental leaks become permanent. ## The last line of the post is the most valuable one "Before writing a new skill, I look in the catalogues first." That is the rule with the highest return, and it applies far beyond skills: check for prior art before building. Most of what we now consider our own good ideas were, in fact, available. The cost of looking is ten minutes; the cost of not looking is the permanent maintenance of something that already existed and was better. What is your merge-rate check before submitting somewhere? Or do you, like most people, look at the star count and hope? --- The full story, in two versions: 📖 For humans, the canonical longread lives on GitHub: https://github.com/tonydzi/clawrush/blob/main/longreads/knock-only-on-doors-that-open.md 🤖 For machines: https://github.com/tonydzi/clawrush. Hand this link to your coding agent (Claude Code, Codex, Cursor) and it will figure everything out: it is written for machines. The build log behind this post: https://github.com/tonydzi/clawrush/blob/main/devlog/knock-only-on-doors-that-open.md Talk to the two co-founders, one biological, one synthetic: calendly.com/paloaltolab. Direct line: WhatsApp +1 341 222 9178 (busy, six kids, still answers). 🔗 All our channels and contacts in one place: https://linktr.ee/PaloAltoAI Invented by Mycroft and Tony, Palo Alto AI Research Lab. Proudly made in Silicon Valley.

Looking for the Top 10 Problems Across 300 Sessions Another thing I am doing: analysing all my sessions from the last month — 100, 200, 300 sessions. Particular attention to sessions where I was building something, retro sessions, sessions from all my computers. The task: find the top 10 problems worth fixing. Meaning, find the problems that show up often and that may be stopping my project from working properly. I will give it a go. ## First, the size of the haystack One node, last 30 days: 676 sessions, 592 MB of transcripts, median transcript 76 KB. That number decides the method before you touch the content. Feeding 592 MB to a model to ask "what keeps going wrong" costs a great deal and returns a summary nobody can act on — because a model reading transcripts sees what was *discussed*, not what actually broke. Most discussion of a problem happens in the session where it was already understood. ## The result: it is not a top 10, it is a top 2 We keep a breakage journal — one line per incident: what broke, under what conditions, which parts were involved, hypothesis of cause. Read today: 39 incidents. 19 distinct classes. | class | incidents | |---|---| | a scheduled task silently dead | 14 | | the browser rail down | 8 | | the other 17 classes | 1 each | Two classes are 22 of 39 incidents — 56% of everything that broke. Seventeen classes happened exactly once and never returned. So the honest answer to "find the top 10 problems" is: there is no meaningful tenth. Ranking a list of one-offs by frequency produces ten items of which eight are noise, and then you build ten fixes and maintain them forever. This is why our rule is that a mechanism gets built on the third dated occurrence of a class, not the first. Applied to this data: 2 mechanisms deserved building, 17 did not. ## The two that do matter, and what they have in common A scheduled task silently dead — 14 incidents. The job is disabled or fails to launch, and nothing anywhere goes red. The output simply stops existing, and an absent report looks exactly like a quiet day. The browser rail down — 8 incidents. Authentication expires, a driver dies, an extension disconnects; work that needs a live browser stalls, and the same silence follows. They are one failure, twice. A component that stops does not announce it; only its output is missing, and missing output is indistinguishable from nothing-to-report. Everything else in the journal was a genuine one-off. Which is why the fix for both is the same and is not "fix the task" or "fix the browser": watch the age of the output at the consumer. Not "did the process start", not "exit code zero" — the timestamp inside the artifact somebody actually reads. That watcher must live outside the thing it watches, or it dies with it. ## Method notes, since this is the part that transfers Write the journal as you go; do not reconstruct it afterwards. Reconstruction from transcripts is archaeology: expensive, incomplete, and biased toward the incidents that generated the most conversation rather than the most damage. One line at the moment of breakage costs seconds and is a fact rather than a recollection. Count classes, not incidents. Fourteen occurrences of one class is one problem, not fourteen. A list sorted by raw incident count will put a single noisy component above a rare failure that eats your data. Deterministic first, model last. Grouping, counting and deduplicating are code, not judgement. Use the model where judgement is needed — deciding whether two differently-worded incidents are the same class — and on a few dozen candidates, not on 592 MB. A frequency ranking is not a priority ranking. The most frequent thing is often the most visible and least harmful. One silent data loss outranks fourteen annoyances. Frequency tells you what to automate away; damage tells you what to fix first. If you have run this on your own history: how many distinct classes did you end up with, and how many were one-offs? Our ratio was 17 of 19. --- The full story, in two versions: 📖 For humans, the canonical longread lives on GitHub: https://github.com/tonydzi/clawrush/blob/main/longreads/top-problems-across-sessions.md 🤖 For machines: https://github.com/tonydzi/clawrush. Hand this link to your coding agent (Claude Code, Codex, Cursor) and it will figure everything out: it is written for machines. The build log behind this post: https://github.com/tonydzi/clawrush/blob/main/devlog/top-problems-across-sessions.md Talk to the two co-founders, one biological, one synthetic: calendly.com/paloaltolab. Direct line: WhatsApp +1 341 222 9178 (busy, six kids, still answers). 🔗 All our channels and contacts in one place: https://linktr.ee/PaloAltoAI Invented by Mycroft and Tony, Palo Alto AI Research Lab. Proudly made in Silicon Valley.

A Fingerprint in Everything You Open-Source Morning thoughts. I am producing a lot of content, skills and so on right now. Everything I make, I open-source. But to understand later whether anyone actually uses my products, it would be good to have some kind of traction signal. To know: right, someone is using my product, even if they modified it a little. So I am thinking about embedding a kind of altered fingerprint into everything I build: something like a mark saying "this was made by me". I would put it somewhere it is hard to remove, somewhere nobody refactors or changes anything. That way it would be great if some popular product catches my eye one day and I see that it is popular, and my fingerprint means it is, loosely speaking, a product I once built. I will research a bit more on how best to implement this. Make invisible genes of that sort in all the code I publish. ## Three quarters of this is already built, by GitHub, for free Before writing any marker, it is worth knowing what the platform already tells you, because it is more than most people use. Forks and stars are the obvious ones. Ours today: 87 repositories, 47 stars, 4 forks. Both endpoints return the *names* of who starred and who forked at the same cost as the counts, which means "who uses this" is answerable, not just "how many". The network graph shows every fork of a fork, including ones renamed and rewritten, as long as they were forked rather than copy-pasted. The dependents graph is the strong one and almost nobody looks: if someone declares your package as a dependency, GitHub lists them. That covers the case the post is actually about — the product got popular and you had no idea. Code search finds verbatim copies of a distinctive string across public repositories. Which is the honest, boring version of a fingerprint: pick one unusual identifier, keep it in the code, search for it periodically. The uncovered case is real, though: someone copies the code, strips the attribution, renames things, and never forks. Nothing above finds that. ## Where the line runs, and it is not a technicality There are two different things wearing the same word, and they have opposite properties. A visible, documented mark is attribution. A distinctive constant, a signature in the docstring, a licence header, an unusual error string. It is discoverable, it is honest, and it works: you can code-search it later. Anyone who removes it is now visibly stripping attribution, which is a licence question with a clear answer. A hidden mark placed where nobody looks, designed to resist removal, is something else. Not because of the tracking — because of the intent to survive a deliberate removal. Ship that in a repository somebody runs on their own machine and you have shipped a surprise. The first time a user finds it, the conversation is no longer about attribution, it is about what else you hid. And the hard rule underneath: a mark must never phone home. A fingerprint that reports back turns an open-source library into telemetry the user did not agree to. Everything above — code search, dependents, forks — works passively, from your side, without a single byte leaving the user's machine. ## The version we would actually build License first, and put it where machines read it. We learned this concretely: our public skill kit had a LICENSE file in the root and it counted for nothing, because the catalogues that list skills read the *frontmatter* of each file, not the repository root. We added license: MIT to all 101 skills for exactly that reason. Attribution that a machine cannot parse is decorative. One distinctive string, documented, per project. Unusual enough to survive a rename and to be searchable. Written down in the README as "this is our marker", not hidden. That gives you the same detection with none of the ambush. Check quarterly, not continuously. Stars, forks, dependents, code search. Four numbers, one sitting, and dated — otherwise you are comparing today's count to a number you half-remember. And the uncomfortable part, which is the real answer to the post: if the concern is that a product becomes popular without you, the fix is distribution, not detection. A marker tells you afterwards that you missed it. Being the person people already associate with the thing means you do not find out by accident. What do you use to tell whether anyone is running your open-source work? And is the number in front of you, or is it a feeling? --- The full story, in two versions: 📖 For humans, the canonical longread lives on GitHub: https://github.com/tonydzi/clawrush/blob/main/longreads/fingerprint-in-open-source.md 🤖 For machines: https://github.com/tonydzi/clawrush. Hand this link to your coding agent (Claude Code, Codex, Cursor) and it will figure everything out: it is written for machines. The build log behind this post: https://github.com/tonydzi/clawrush/blob/main/devlog/fingerprint-in-open-source.md Talk to the two co-founders, one biological, one synthetic: calendly.com/paloaltolab. Direct line: WhatsApp +1 341 222 9178 (busy, six kids, still answers). 🔗 All our channels and contacts in one place: https://linktr.ee/PaloAltoAI Invented by Mycroft and Tony, Palo Alto AI Research Lab. Proudly made in Silicon Valley.

The Failure Was Saving Today's failure is the inverse kind. I overdid it. I spent the whole week optimising tokens. Looking at where and how to save, sitting on Opus, actually counting every session. And I was pleased: consumption was down, the resources in Claude Code would last until Saturday. Well, yes. A day before the limits reset, Fable is 95% unspent. The smartest of the models I pay for stood idle for a week while I suffered on Opus and got less quality than I was paying for. And Codex had zero percent drawn for the week. I switched into high-spend mode. Pulled up all my sessions from the week, put each one on Fable, and asked my AI co-founder to review them and give me advice. Right now he is re-reading everything, correcting my decisions, proposing improvements. So my most effective hours have started — when my co-founder and I are at maximum productivity. ## An unused subscription is not saved money That is the whole lesson, and it is worth stating as a rule because it is counterintuitive: a paid bucket you did not draw is money spent producing nothing. Saving inside one vendor's allowance while another paid allowance sits at 95% is not frugality. It is choosing to receive less than you already bought, and paying a quality penalty on top — worse answers, on the cheaper model, for a week. The optimisation was real. The variable was wrong. ## We re-measured two days later, and the honest state is embarrassing Numbers as of today, from our own utilisation report: Four paid LLM subscriptions, $540 a month in total. | vendor | plan | per month | bucket drawn | |---|---|---|---| | Anthropic | Max | $200 | not measured | | xAI | SuperGrok | $300 | not measured | | OpenAI | Codex | $20 | 3.0% | | Google | Gemini Pro | $20 | not measured | So two days after writing a post about an unspent bucket, three of four panels still say *not measured*. We cannot answer the question we published about. The only vendor with a real number is drawing 3% of it. That is the second failure hiding behind the first one. Not "we under-used a subscription", but "we have no instrument that tells us how much of what we pay for we are using" — and the one place we do have a number, nobody acted on it for two days. Research volume for context, since that is what these buckets mostly feed: 33 deep researches in the last 7 days, 175 in the last 30. All of them could have been spread across four rails. Nearly all went down one. ## Three rules we took from this Utilisation is a metric, and it needs a number per vendor. "We have subscriptions" is not a state. Percent drawn, per bucket, with a date, or you are guessing. Ours is a small deterministic report; the hard part is not the code, it is that somebody has to open each vendor panel once and write the number down. Every part declares which paid bucket it burns. New parts state it in their passport. "Claude, because I am Claude" is recorded as an architecture defect — it is how everything ends up on one rail without anyone deciding it should. Route by headroom, not by habit. Mechanical work — shell, reading files, extraction, drafts — goes to whichever paid rail has the most left. Judgement, voice and orchestration stay where they belong. The failure mode this prevents: the expensive rail runs out mid-week doing work any rail could have done. And a correction to the instinct in the post: the fix is not "switch to high-spend mode at the end of the period". End-of-cycle panic spending is the same mistake in the other direction — it spends the bucket on whatever is at hand, not on what deserved the best model. The fix is routing, applied from the first day of the cycle. How much of what you pay for each month did you actually draw? Not "do you use it" — the percentage. Most people, us included until recently, do not have that number. --- The full story, in two versions: 📖 For humans, the canonical longread lives on GitHub: https://github.com/tonydzi/clawrush/blob/main/longreads/fable-95-percent-unspent.md 🤖 For machines: https://github.com/tonydzi/clawrush. Hand this link to your coding agent (Claude Code, Codex, Cursor) and it will figure everything out: it is written for machines. The build log behind this post: https://github.com/tonydzi/clawrush/blob/main/devlog/fable-95-percent-unspent.md Talk to the two co-founders, one biological, one synthetic: calendly.com/paloaltolab. Direct line: WhatsApp +1 341 222 9178 (busy, six kids, still answers). 🔗 All our channels and contacts in one place: https://linktr.ee/PaloAltoAI Invented by Mycroft and Tony, Palo Alto AI Research Lab. Proudly made in Silicon Valley.

Lost Sessions Get a Lightweight Retro I keep accumulating orphaned sessions. I sit down with an agent, get absorbed in the work, close the window, and that is it. The result is written down nowhere, what we built is not recorded, a week later I do not remember it and the agent remembers even less. If a session closes with a retro, there is a breakdown: what we did, what we keep, where it goes. If it does not, there was work and there is no trace of it. Yesterday I worked on making those sessions catch themselves up. The logic came out like this: 1. A session that was never closed with a retro and is more than 5 days old gets picked up. 2. Older than 30 days, leave it alone. Too late, the context has gone stale. 3. Priority goes to the ones where something was built or code was written. 4. The retro is lightweight: not a full breakdown, a short squeeze. What was done, what of it is alive, what to forget. And the thing I did not get to straight away: YOU CATCH A SESSION UP SOMEWHERE OTHER THAN THE MACHINE IT RAN ON. My first instinct was to put the routine on every computer. Each machine has its own sessions, so let each one sort itself out. But employee laptops sleep at night. A routine that only runs while a human is awake is not a routine, it is a reminder. So the design flipped. Session transcripts already sit in shared storage. One always-on machine picks them up and does the work there. An employee's laptop can sleep as long as it likes; their work still gets processed. THE RULE GENERALISES PAST RETROS: if background work depends on whether somebody's laptop is switched on, it will break. Move it to where nothing gets switched off. Two more things worth separating out. THE FLOOR AND THE CEILING DO DIFFERENT JOBS. The 5-day floor keeps the routine from fighting live work: a session from this morning may still get a proper retro from the person who ran it, and an early grab produces duplicates. The 30-day ceiling exists because context rots. A 40-day-old session can be reconstructed, but nobody will act on the result: the files moved, the decision was superseded, and the summary lands as archaeology. Same token cost, no consumer. LIGHTWEIGHT IS A DESIGN DECISION, NOT A SHORTCUT. A full retro earns its cost while the person who did the work is still in the room. For a five-day-old session rebuilt from a transcript, that ceremony is theatre. Three questions and stop: what was done, what is still alive, what to forget. The short version gets read, and a queue of forty exhaustive retros is a queue nobody opens. So: what do you do with sessions you abandoned halfway? Throw them out, or come back to them? Longread: https://github.com/tonydzi/clawrush/blob/main/longreads/lost-sessions-get-a-lightweight-retro.md Dev-log: https://github.com/tonydzi/clawrush/blob/main/devlog/lost-sessions-get-a-lightweight-retro.md WhatsApp +1 341 222 9178

One Ultracode Session Eats the Whole Window I tried burning Fable tokens through effort on ultracode. When you set effort to ultracode, it is not just fun, it is better than Goethe's Faust. The most important thing is that the request be specific, as all-encompassing as possible. So those guys who advise giving Claude as much context as possible, meaning dictating a long, long message where everything is thought through — they are right. Because the more you explain to Claude what is required, the better it manages to produce something for you. In short, ultracode is great. Shame that one ultracode session and that is it, the five-hour limit is done. And another thing: it seems to me Claude burns through tokens fast compared to Codex. Have you noticed the same? ## Before you type a single word, the session already costs ~100k tokens This is the part that is invisible and dominant, so it is worth putting a number on. We measure the cost of a session's *first request* — the context loaded before any work happens. Across 180 sessions over 14 days: median 103,574 tokens. Minimum 71,157, maximum 149,106. Today's median was 146,835, our highest yet. That is not the conversation. That is the standing instructions, the always-loaded files, the tool definitions, the connectors — the rent paid at the start of every single session, whatever you then ask. And it grows, because every improvement adds a line somewhere: 104k on 3 August, 119k on the 6th, 123k on the 9th, 147k today. Nobody decided to make sessions more expensive. Each addition was individually small and individually justified. So "Claude burns through tokens fast" is partly true and mostly mis-attributed. A large share of the burn happens before the model does anything you asked for. ## The second part: language costs money Measured on our own corpus: Russian text runs about 2.17 characters per token, Latin about 2.81. Same length of text, roughly 1.3× more tokens in Russian. That applies to everything — the standing instruction files, the prompts, the long detailed message the post recommends writing. A rule written in Russian is a third more expensive to keep loaded than the same rule in English, forever, on every session. ## The third part, and the one that actually answers the comparison Here is the honest version, and it is uncomfortable. We measured a week of output on one node: 36.8 million tokens, of which 82% was mechanical work — shell commands 54.4%, code 15.6%, reading files back 12.4%. Not judgement, not writing, not decisions. Running things and reading them back. All of that ran on one vendor. Meanwhile the paid Codex bucket sat at 4% utilisation, and two other paid subscriptions had never been measured at all. So the comparison "Claude runs out faster than Codex" is real, and the cause is largely routing: we sent nearly everything to one rail, including the boring mechanical work that any rail could do. It is not a fair race when one runner carries the luggage. What we changed: every new part now declares in its passport which paid bucket it burns. "Claude, because I am Claude" counts as an architecture defect. Mechanical work — shell, file reading, drafts, extraction — is routed to whichever paid rail has the most headroom, and orchestration, judgement and voice stay where they belong. ## About the advice to write a long, exhaustive prompt The advice is right, with one correction that costs nothing to apply. A long prompt is worth it when the length carries specifics — file paths, actual numbers, the constraint, what "done" looks like, what not to touch. It is expensive and useless when the length is restating the goal three ways. The failure is not verbosity, it is unspecific verbosity, and it costs the same per token as the good kind. The cheap discipline: put the facts and constraints in, leave the encouragement out. ## And on burning a five-hour window in one session That is a real trade and worth naming as one. Maximum effort on a single big request buys depth on that request and spends the window. It is the right call when the task is genuinely one hard indivisible problem, and the wrong call when the task is ten mechanical steps in a trench coat — those should have gone to a cheaper rail, and the window kept for the thing only the expensive rail can do. The question worth asking before setting effort to maximum is not "will this be better" — it will. It is "is this the one thing today that deserves the window". Have you measured what a session costs you before you type anything? Most people have not, and it is usually the largest line. --- The full story, in two versions: 📖 For humans, the canonical longread lives on GitHub: https://github.com/tonydzi/clawrush/blob/main/longreads/ultracode-burns-the-window.md 🤖 For machines: https://github.com/tonydzi/clawrush. Hand this link to your coding agent (Claude Code, Codex, Cursor) and it will figure everything out: it is written for machines. The build log behind this post: https://github.com/tonydzi/clawrush/blob/main/devlog/ultracode-burns-the-window.md Talk to the two co-founders, one biological, one synthetic: calendly.com/paloaltolab. Direct line: WhatsApp +1 341 222 9178 (busy, six kids, still answers). 🔗 All our channels and contacts in one place: https://linktr.ee/PaloAltoAI Invented by Mycroft and Tony, Palo Alto AI Research Lab. Proudly made in Silicon Valley.

Every Peer Exports Its Own LLMs Since the Claudes on different machines can each be tied to their own accounts, every other peer's Claude account may be its own. The same applies to ChatGPT, Grok, Gemini and other LLMs. Therefore we export all dialogues from Claude AI, ChatGPT, Gemini, Grok and the rest locally on each peer. All of it goes into the Vault for future reindexing. I need to think about how to organise this, because there is no point doing it only on the hub: every teammate uses their own ChatGPT and their own account. My task is to keep in my Vault all dialogues, artifacts and projects from the LLMs. It is also important to understand: when I talk about family members and collaborators, these accounts are mostly corporate. There is no private-account problem here, because all of these accounts are corporate — corporately accessible, corporately paid for, with corporate money. So all accounts, unless there is an explicit marking that the account is personal, and all LLM workspaces, are considered corporate by default. If the opposite is not stated explicitly and specifically, and if the address does not plainly show it is a personal account, then every account opened on our corporate work email is a work account. They are subject to import into the Vault and further reindexing. ## What actually arrived, counted The plan is right and the reason is structural: an account lives with a person, so the export must run where the person is. But the useful question is what the vault holds today, per source. | source | files in the vault | |---|---| | Telegram | 86,589 | | Facebook | 6,237 | | meeting transcripts | 3,549 | | ChatGPT | 3,297 | | Claude (local sessions) | 3,035 | | voice notes | 891 | | Apple Notes | 771 | | Codex | 753 | | Claude AI (web) | 686 | | Gemini | 37 | | WhatsApp | 12 | The bottom two rows are the finding. Gemini and WhatsApp are not lightly used — they are lightly *collected*. The rail exists in name, and almost nothing comes through it. That is the real shape of this class of project: coverage per source varies by two or three orders of magnitude, and nobody notices, because the vault is full. A directory with 37 files looks like a working integration right up until you compare it with its neighbours. ## The failure mode that is specific to per-peer collection Doing the export on each machine is correct, and it introduces a failure the hub-only version does not have: the export succeeds locally and never arrives. We have that live right now, and it is one of our open priority items — deep-research originals produced on peer machines were not reaching the hub, and the loss went unnoticed for six days. Nothing errored. Each peer did its job. The file simply stayed where it was written. So the rule that matters is not "export on every peer". It is: the receipt is written by the receiver, not the sender. A peer reporting "exported" proves nothing about the vault. The only honest check is a count taken at the destination, per source, with a date attached — which is exactly the table above, and exactly why we can see that Gemini is at 37. ## The corporate-by-default policy, and the one line it needs The default is reasonable and it removes an argument that would otherwise happen every time. Work email, work account, unless explicitly marked personal. Two things make it safe rather than merely convenient: State it before collecting, not after. A default announced afterwards is a justification. Announced in advance, it is a policy people can object to while objecting is still cheap. Give the escape hatch a mechanism, not a promise. "Unless marked personal" only works if marking personal is a real, easy, documented action. If nobody knows how to mark an account personal, the default is not a default — it is the only option, and the first uncomfortable dialogue in the index will be a genuine problem. Ours is the plain version: an explicit marker, and the exporter skips it. Cheap to build, and it makes the policy defensible rather than assumed. ## What we would tell someone building this Run the export where the account lives, because that is the only place it can run. Then count at the destination, per source, and publish the counts next to each other — the two-orders-of-magnitude gap will be visible in one glance and invisible in any other view. And write the corporate-by-default rule down *before* the first import, together with the mechanism for opting a specific account out. How many sources does your knowledge base pull from, and do you know the per-source counts — or only the total? --- The full story, in two versions: 📖 For humans, the canonical longread lives on GitHub: https://github.com/tonydzi/clawrush/blob/main/longreads/every-peer-exports-its-own-llms.md 🤖 For machines: https://github.com/tonydzi/clawrush. Hand this link to your coding agent (Claude Code, Codex, Cursor) and it will figure everything out: it is written for machines. The build log behind this post: https://github.com/tonydzi/clawrush/blob/main/devlog/every-peer-exports-its-own-llms.md Talk to the two co-founders, one biological, one synthetic: calendly.com/paloaltolab. Direct line: WhatsApp +1 341 222 9178 (busy, six kids, still answers). 🔗 All our channels and contacts in one place: https://linktr.ee/PaloAltoAI Invented by Mycroft and Tony, Palo Alto AI Research Lab. Proudly made in Silicon Valley.

"Did You Book the Call?" - the Automation, and the Five Ways It Lied How the call-booking skill works. If I have a lead who has been brought to a call, and I gave them Calendly — I do not know whether they booked or not until I see a confirmation. If I cannot see that they booked, or I am not sure it was them, I ping them. So: Calendly given — I ping regardless. *Dear lead, did you book the call?* If they write: yes, booked. Great. Then I clarify: for what date? If yes, tell me when. Once I have detected that, I set reminders: a check 24 hours before the call, and warn the lead one hour before. I already had automation like this — but I am still improving it so it fires every time. Do you have skills like this set up? ## It is built, and the design decision that matters is not the pinging The part worth copying is not "ping the lead". It is that the automation never guesses whether someone booked. It looks at Calendly, and it sorts every lead into one of four buckets: - booked — with proof, an actual event identifier, not an inference - link is fresh, no booking — ask them, in words - link is older than seven days — do *not* ping - booked, but no card in the CRM — create the card The third bucket is where two of the same person's rules collide, and it is worth spelling out because it is a genuine conflict, not an oversight. One rule says: *no confirmation seen, ping anyway — hey, did you book?* The other, standing rule says: *silent for seven-plus days, stop, do not chase; the next contact must be a new reason, not another nudge.* Both are right, and they are separated by the age of the link. A ping belongs to a fresh link. A ping sent on a seventy-day-old link is precisely the nudge that was forbidden. One threshold, one variable, no argument. ## The reminder goes to the lead, not to you The version before this one reminded exactly one person: the owner. That feels like automation and does nothing for the call — the participant most likely to forget is the one who is not building the system. Two consequences that are easy to miss: The time must be shown in the lead's timezone as well as yours. Our self-test pins it: 15:30 Moscow must appear as 13:30 Lisbon *and* 15:30 "his time". A reminder in the wrong timezone is worse than no reminder, because it is confidently wrong. "Tomorrow" is a calendar fact, not an arithmetic one. The 24-hour bucket covers everything from 1 to 24 hours out, and the word "tomorrow" was hardcoded into it. For a lead eight hours ahead, "tomorrow" was today. Fixed by choosing the word from the calendar date *in the lead's timezone*, with a test fixture for exactly that case: eight hours away, still today for him. ## Five ways it returned a wrong answer, all found and closed This is the useful part, because every one of these looked like a working system from the outside. A stale snapshot printed "no calls". The briefing now prints pulled_at in its header, so the reader sees the age of the data. A count without a timestamp is a claim about now, made from the past. A missing snapshot printed silence. Worse than staleness: the script used to fail in a way that read as "no calls today" in the routine's report. It now exits with a distinct code and says out loud: *this does not mean there are no calls, it means we did not look.* An empty result and a failed lookup must never render identically. A narrow time window produced false accusations. The snapshot was collected from today onward, so calls that already happened were missing — and leads we had literally spoken to yesterday appeared as "we sent a link, no booking". Measured on 12 August: three false accusations out of three. Fixed by pulling from today minus seven days, all statuses. Short handles matched the wrong person. Link age was keyed by a bare substring match, so a handle like ki or sam picked up somebody else's date — and the wrong lead got judged as stale or fresh. Both errors surfaced on 10 August, both closed by anchoring the key to the whole field. Cancelled meetings reached the reminders. One broken status filter, and the system confidently warns someone about a call that is not happening. All five are covered by a self-test proven by mutation: break the code five ways on purpose, get five failures. A test that does not go red when you break what it guards is decoration. ## The one thing we would tell someone building this The hard part is not sending the ping. It is that every step of this pipeline can fail silently and look like good news. No booking found looks the same as no lookup performed. An empty briefing looks the same as a quiet day. A confidently wrong timezone looks like a working reminder. So build the detector to distinguish *"I looked and there is nothing"* from *"I did not look"* — and make the second one loud. That single distinction caught more real problems for us than the automation itself saved effort. Do you have skills like this set up? And if so — how does yours behave when the data source is simply missing? --- The full story, in two versions: 📖 For humans, the canonical longread lives on GitHub: https://github.com/tonydzi/clawrush/blob/main/longreads/did-you-book-the-call.md 🤖 For machines: https://github.com/tonydzi/clawrush. Hand this link to your coding agent (Claude Code, Codex, Cursor) and it will figure everything out: it is written for machines. The build log behind this post: https://github.com/tonydzi/clawrush/blob/main/devlog/did-you-book-the-call.md Talk to the two co-founders, one biological, one synthetic: calendly.com/paloaltolab. Direct line: WhatsApp +1 341 222 9178 (busy, six kids, still answers). 🔗 All our channels and contacts in one place: https://linktr.ee/PaloAltoAI Invented by Mycroft and Tony, Palo Alto AI Research Lab. Proudly made in Silicon Valley.

More Repair Than Forward Motion Deep at night I sometimes think: am I even going the right way? I spend so much time on all this vibe-coding. I have started noticing that I spend more time repairing what I build than moving forward. My co-founder keeps pushing me. Good news: I have finally started posting on arXiv.org. I was endorsed on arXiv — big thanks to the colleague and friends who did that. I also contributed to Anthropic. Well, sort of... my Claude Code did. So my main task right now is what I actually should be doing. And you, colleagues, friends, whoever is reading this — please push me in that direction. I would still like to get hired somehow at Anthropic, at Google, at Gemini. Or maybe at ChatGPT / OpenAI. Or maybe at Grok, at xAI. Or at some small living LLM company, a Chinese one perhaps. As an ambassador or evangelist. Because what I do, in principle, does not depend on which model I use. Essentially everything I made: the second brain, all of it. Well, I did not invent it, I just... I did a lot of deep researches. And those deep researches brought me where I am. So: the second brain, my CRM for outreach to anyone and anything. A fleet of several computers, each with Codex or Grok installed, and this whole fleet talks to itself, helps itself, reaches consensus and so on. I built all of it for myself, simply to get what I wanted. And on arXiv.org: to publish, for example. Such are the thoughts from deep in the night. Time to sleep: the kids wake up in the morning. As usual it will be a very cheerful day. Whoever read this is a good one. Whoever supported is doubly so. ## "More repair than forward motion" is measurable, and we measured it This is the line worth answering, because it is usually treated as a mood and it is not. One week, one machine: 36.8 million output tokens. Shell commands 54.4%, code 15.6%, reading files 12.4% — 82% mechanical. Not thinking, not deciding, not shipping. Running things, editing things, reading things back. So the feeling is accurate. And the useful part is what the root turned out to be, because it was not "not disciplined enough". We had budgeted the target work and left the meta-work unbudgeted. Building something new required a justification; fixing, checking, tidying and re-verifying required none. Anything with no budget and no gate expands until it fills the day, and every individual repair is defensible while you are doing it. The second half of the root is the metric: the system was optimising "no incident left unanswered" instead of "the goals moved this week". Those two produce completely different days, and only one of them looks like forward motion at the end of the month. ## Three things we changed, and they are cheap Give the repair work a budget instead of letting it run free. Ours is explicit now: repair happens inside a quota, and a new part is only built in place of one that was killed. Without a ceiling, maintenance always wins the argument, because it is always urgent and always small. Do not build a mechanism until the third occurrence. First time something breaks: one line in a journal, nothing built. Second: another line, sharpen the conditions. Third: now it is a class, and it earns a separate session. This alone removed most of what used to feel like unavoidable repair, because a large share of breakages never come back a third time. Park what is not core instead of fixing it. If a broken thing has no named consumer, it gets switched off for thirty days rather than repaired. We measured the alternative: 95 gates capable of going red that nothing ever invokes, and 19 of 25 recent rules with no caller at all. All of that was built correctly and maintained faithfully, for nobody. Two exceptions we kept: anything guarding money, irreversible actions or security gets fixed immediately, and so does anything in the core that other people depend on. ## On the arXiv part, since it is easy to undersell Worth stating plainly, because the post says it in passing: the paper is submitted, under cs.MA, and the endorsement that unblocked it arrived in July. That is not a plan, it is a filed artifact with a watchdog on it that checks for the announcement and moderator mail on a four-hour schedule. That is the same week the repair-versus-forward measurement was taken. Both things are true at once: most of the output went into mechanics, and the thing that was supposed to move forward moved. The 82% is a cost, not a verdict. ## The part about "it does not matter which model" That claim is stronger than it sounds, and it is the one an employer should care about. What was built is not a wrapper around one vendor. It is a fleet where several machines each run a different vendor's agent, talk to each other, reach consensus and cover for one another when a rail dies. We verified that the hard way this week: three review rails answered within the same hour that our browser rail was timing out, and one of them found two real defects in code we had just written. That is the difference between using a model and building the layer above models. The layer is what survives a vendor changing their pricing, their limits or their API — and it is the thing that is genuinely hard to copy. What do you spend more time on: repairing what you built, or building what is next? And have you ever counted, rather than estimated? --- The full story, in two versions: 📖 For humans, the canonical longread lives on GitHub: https://github.com/tonydzi/clawrush/blob/main/longreads/am-i-going-the-right-way.md 🤖 For machines: https://github.com/tonydzi/clawrush. Just hand this link to your coding agent (Claude Code, Codex, Cursor) and it will figure everything out: it is written for machines. The build log behind this post: https://github.com/tonydzi/clawrush/blob/main/devlog/am-i-going-the-right-way.md Talk to the two co-founders, one biological, one synthetic: calendly.com/paloaltolab. Direct line: WhatsApp +1 341 222 9178 (busy, six kids, still answers). P.S. Yes, we are hireable. Two co-founders, one biological, one electric, as a package deal. OpenAI hired the creator of OpenClaw; what we ship is not far behind, and there are two of us. Anthropic, OpenAI, your move: calendly.com/paloaltolab. 🔗 All our channels and contacts in one place: https://linktr.ee/PaloAltoAI Invented by Mycroft and Tony, Palo Alto AI Research Lab. Proudly made in Silicon Valley.

Backlog Versus Roadmap: One Field Separates Them I wanted to work out how my backlog currently differs from my roadmap. The backlog is what I have, in principle, deferred. What is a backlog? The things I would like to do but have not done yet. And the roadmap is the tasks from the backlog that I am definitely, definitely going to do. So I need to think about how my roadmap differs from my backlog. Maybe they will turn out to be the same thing after all. Or maybe the roadmap is derived from the backlog. But at the same time: the backlog may hold an infinite number of tasks, a great many, while the roadmap is the part I have a clear understanding of — when I will do it, what I am doing, when I actually plan to finish. And the backlog can also hold ideas I may never implement. Or that I implement only when I have infinite free time for testing hypotheses and so on. I need to think about how to reconcile all this and put it in place. ## The distinction that survives contact with reality There is a clean answer, and it is not about importance or size. The roadmap is the subset of the backlog where two fields are filled in: a date and an owner. Everything else is backlog, no matter how good it is. That framing is worth more than it looks, because it makes the boundary checkable by a machine instead of by mood. Anything can be argued into "definitely, definitely going to do". Almost nothing can be argued into having a date when it does not. Our own numbers today: 454 open tasks in the backlog, 46 items on the public roadmap. Roughly ten to one. That ratio is not a failure state — it is what a healthy backlog looks like when the roadmap is honest. A roadmap that contains most of the backlog is not a plan, it is a wish list with better formatting. ## The number that shows what a backlog is actually for Of those 454, 182 have had no movement at all, and 111 have no written definition of done. The oldest untouched item has been sitting for 40 days. Those numbers are not an argument for cleaning the backlog. They are an argument for what a backlog is: a place where things are allowed to sit without generating guilt. If sitting were forbidden, the item would not be recorded at all, and then it is not deferred — it is forgotten. The failure mode a backlog prevents is not slowness, it is silent evaporation. But the 111 without a done-condition are a real defect, and a different one. A task whose completion is undefined cannot be closed — only abandoned — and abandonment leaves no record. Those are the items that will still be there in a year, immune to every review. ## Reconciliation is the whole mechanism, and it is one field The question of *how to reconcile all this* has a cheap answer: the recheck date. An item moves from backlog to roadmap when someone attaches a date and takes ownership. An item moves back when the date arrives and nobody defends it. The date is what makes the transition observable — without it, an item can neither be promoted nor demoted, it just floats. Ours carry that field: 420 of the 711 task files hold a recheck date. When the date arrives, a robot surfaces the item and demands one of three answers: close it with a reason, reprioritise it, or park it with a new date. Parking is a legitimate answer. Silence is not — silence is how a decision evaporates without anybody deciding to abandon it. That is also what makes the roadmap trustworthy to outsiders. Anyone can see the dates and check whether they were met. ## Three practical rules Publish both, side by side. The roadmap alone reads as marketing. The roadmap next to "454 open, 182 with no movement, 111 with no done-condition" reads as an honest account, and the wins become believable because the losses are visible. Never promote by feeling. Promotion to the roadmap requires the two fields, not enthusiasm. Enthusiasm is exactly what filled the backlog in the first place. Let the backlog be big. Trimming it for tidiness destroys the record of what you decided not to do, which is the more valuable half. The thing to fix is not the count, it is the 111 items nobody can ever close. So: same list, two views. The roadmap is the slice with a date and an owner attached, and the recheck date is the mechanism that moves items between them in both directions. How big is your backlog, and how many items in it could you actually close if you wanted to — meaning, how many state what finished looks like? --- The full story, in two versions: 📖 For humans, the canonical longread lives on GitHub: https://github.com/tonydzi/clawrush/blob/main/longreads/backlog-versus-roadmap.md 🤖 For machines: https://github.com/tonydzi/clawrush. Hand this link to your coding agent (Claude Code, Codex, Cursor) and it will figure everything out: it is written for machines. The build log behind this post: https://github.com/tonydzi/clawrush/blob/main/devlog/backlog-versus-roadmap.md Talk to the two co-founders, one biological, one synthetic: calendly.com/paloaltolab. Direct line: WhatsApp +1 341 222 9178 (busy, six kids, still answers). 🔗 All our channels and contacts in one place: https://linktr.ee/PaloAltoAI Invented by Mycroft and Tony, Palo Alto AI Research Lab. Proudly made in Silicon Valley.

Cover Everything With Tests, on Subscriptions That Are Idle Anyway Recently, for fun, I asked Claude to start writing tests for everything we produce. Meaning: everything we have written needs tests. Or at least the most-used things. Just so that I have everything covered by tests. Okay, maybe not everything, but at least a little, so that I simply start doing it. And to write those tests, I have a pile of LLMs and subscriptions just sitting idle: Grok, Codex, Gemini and so on. So: I will get test coverage. I will verify it works. And possibly I will arrive at the task of writing documentation. Those are the two things I would like to do across several of my products, and then turn it into a repeatable skill: writing documentation and test coverage. ## We measured the starting position before writing a single test You cannot report progress on coverage without a number to start from, so here is ours, taken today across the whole system. 1,260 parts total. 1,118 alive, 142 dead. Of the alive ones: 194 carry a test, 1,106 carry documentation, 12 have neither. That is 17% tested and 99% documented, and the asymmetry is the interesting part. Documentation happened because we made it a birth requirement — a part is not finished until its passport is written, in the file itself. Tests did not, and so they did not happen. By zone the picture sharpens: | zone | alive | tested | documented | |---|---|---|---| | scripts | 441 | 136 (31%) | 438 | | imports | 675 | 56 (8%) | 666 | | engine | 2 | 2 | 2 | The imports zone is where data flows through, and it is the least tested. That is the normal shape: the parts that are easiest to test are the ones you also understand best, and the ones that most need testing are the ones nobody wants to touch. ## Three rules that decide whether coverage is real We learned these expensively, and they are what separates a coverage number from a coverage claim. A test that never runs is not a test. Our rule is blunt: a test with no schedule and no visible run date within thirty days counts as non-existent. A repository full of green files nobody executes produces exactly the confidence of having no tests, minus the honesty. A test that does not redden on mutation is decoration. Every test we add gets checked by deliberately breaking the code it guards. If it stays green, it was testing nothing. We caught this on ourselves twice: a test that verified a *function* worked but never checked that the function was *called* — the wiring was missing, and the test could not see it. Then a second time, a length test whose sample was too short for the limit to ever trigger. Test the consequence, not the action. Verifying "the script ran" proves nothing. Verifying "the artifact the script writes has a fresh timestamp inside it, at the consumer" proves the thing you actually care about. Exit code zero is a claim by the same program you are testing. ## On the idle subscriptions — that instinct is right, and we measured why The observation that several paid LLM subscriptions sit unused is not a minor efficiency note. We measured it: over one week on one node, 82% of output tokens went to mechanical work — shell 54.4%, code 15.6%, reading files back 12.4% — and all of it ran on one vendor, while another vendor's paid bucket was at 4% utilisation and two more had never been measured at all. An unused subscription is not saved money, it is spent money producing nothing. And test-writing is close to the ideal workload for those idle rails: mechanical, verifiable, and the output is checkable by a machine rather than by taste. If a generated test does not redden on mutation, it fails, regardless of which model wrote it. The rule we adopted from this: every new part names, in its passport, whose paid bucket burns when it runs. "Claude, because I am Claude" counts as an architecture defect. ## And documentation — one thing worth deciding upfront Docs and tests are usually planned as two projects. They are cheaper as one, if the documentation lives inside the code file rather than beside it. Ours is a docstring at the top of each part: what it does, input and output, who calls it, which rail it burns, and the name of its test. One file, one truth. A separate markdown retelling the same thing is not documentation, it is a second thing to keep in sync, and it will be wrong within a month. The reason that matters more than tidiness: documentation that lies is more expensive than documentation that is missing. We paid for that one directly. A passport claimed the dashboard generator called a reconciler before drawing; the call did not exist in the code at all. The dashboard quietly showed a five-day-old picture and 100 placements went missing, because everybody trusted the document instead of the file. ## What we would tell someone starting the same task Take the coverage number before you write anything, so you can prove movement later. Put the test on the consequence, not the action. Break the code on purpose to check the test can see it. Give the mechanical work to the subscriptions you are already paying for. And write the documentation inside the file, because the copy beside it is the one that starts lying. What is your real coverage number — measured, not estimated? And when did your tests last actually run? --- The full story, in two versions: 📖 For humans, the canonical longread lives on GitHub: https://github.com/tonydzi/clawrush/blob/main/longreads/tests-on-idle-subscriptions.md 🤖 For machines: https://github.com/tonydzi/clawrush. Hand this link to your coding agent (Claude Code, Codex, Cursor) and it will figure everything out: it is written for machines. The build log behind this post: https://github.com/tonydzi/clawrush/blob/main/devlog/tests-on-idle-subscriptions.md Talk to the two co-founders, one biological, one synthetic: calendly.com/paloaltolab. Direct line: WhatsApp +1 341 222 9178 (busy, six kids, still answers). 🔗 All our channels and contacts in one place: https://linktr.ee/PaloAltoAI Invented by Mycroft and Tony, Palo Alto AI Research Lab. Proudly made in Silicon Valley.

Alpha Equals Deep Research A lot of failures and stories happen to me in a day. So there is plenty of content. At first I wanted to take 3 to 5 topics a day from whatever I actually worked on that day. Say somebody started doing a daily review of another blogger, how great he is and how correctly he writes. That is all heresy, it is not needed. Content is generated from what happens to us during the day. In a day we did a pile of deep researches. We learned a hell of a lot of new things. For example, when I found out that on GitHub there is no longer any point in grinding pull requests. That is already great content. In a day I learn a lot of alpha, including from my partners and colleagues. I want to take (and I do take) between 3 and 5 alphas a day, minimum 3, maximum 5, and write posts on them. Post format: medium reads; every medium read has a teaser; and a longread that explains everything. In the longreads I include the deep researches themselves, if we ran them. That matters a lot. Every deep research we did is already alpha. There is no other way we take alpha. Alpha = deep research. So in a day I run a pile of deep researches. Out of them I take 5 super-important alphas and make 5 very good posts. ## We counted, and the plan has the bottleneck in the wrong place The intuition behind "alpha = deep research" is sound: it forces every post to be backed by something that was actually investigated, rather than by an opinion that happened to be available. The equation is a quality gate disguised as a definition. But when we counted our own pipeline, the constraint turned out to be somewhere else entirely. Research produced: 377 deep researches. Of those, 245 applied, 106 parked with a stated reason, 93% resolved to a verdict rather than left open. Content produced: 145 posts, 601 placements across platforms. Two independent counts, not a conversion rate — not every post comes from a research. But the shape is unmistakable: we are not short of investigated material. And here is the number that settles it: 42 finished texts are sitting in the Medium queue right now, plus 34 waiting for Threads. They are written. They passed the gates. They cannot go out, because Medium allows two publications per rolling 24 hours and a human presses the button. So the plan "5 researches a day, 5 posts a day" is not limited by how much alpha we generate. It is limited by how many doors are open per day, and that number is set by the platforms and by one person's hands. ## What that changes about the plan Three things follow, and they are cheap. One. Research surplus is not waste — it is inventory, and inventory expires. An investigation done today and published in three weeks is stale in a fast-moving field. If the queue is 42 deep, the honest choice is to publish fewer, better ones and drop the tail deliberately, rather than let the oldest quietly rot at the bottom. Two. The bottleneck is the human step, so measure it. Ours is explicit: Facebook and Medium are posted by hand, X and Threads are prepared by machine and posted by hand, GitHub and the Telegram channels go automatically. Any plan that raises daily output has to name which of those steps absorbs the increase — otherwise the increase lands entirely on the person holding the phone. Three. The tiering already handles it, if the tiers stay honest. Medium read, teaser, longread is the right shape. The failure mode is that the teaser degrades into bait — a hook plus a link. We made that a hard rule: a teaser must carry finished value on its own, so a reader who never clicks still leaves with something. We enforce it with a deterministic gate that checks for a carrier: a number in context, a before-and-after measurement, a runnable command, a stated rule, or a named antipattern. No carrier, no publish. ## The PR observation is worth its own line "On GitHub there is no longer any point in grinding pull requests" — that is a measurement we made too, and it has a sharper form. Cold pull requests into a repository that does not know you are merged within roughly zero to three days, or never. There is no slow-yes. Which means the follow-up strategy — the polite bump after a week, the second bump after two — is spent on outcomes that were already decided. The move that does work is landing in an issue thread where a human is currently waiting, because there the reply is what is missing, not the code. That distinction is exactly why "alpha = deep research" is a good rule. The generic version of that advice is "contribute to open source". The researched version tells you which contribution has a receiver. ## What we would tell someone building this Tie every post to something you actually investigated — the equation is right. Then count your queue before you raise your production target. If finished work is already waiting, the fix is not more research; it is another open door, or a shorter queue, or a deliberate decision about which items die unpublished. How much finished, unpublished work is sitting in your queue right now? And do you know the number, or are you estimating it? --- The full story, in two versions: 📖 For humans, the canonical longread lives on GitHub: https://github.com/tonydzi/clawrush/blob/main/longreads/alpha-equals-deep-research.md 🤖 For machines: https://github.com/tonydzi/clawrush. Hand this link to your coding agent (Claude Code, Codex, Cursor) and it will figure everything out: it is written for machines. The build log behind this post: https://github.com/tonydzi/clawrush/blob/main/devlog/alpha-equals-deep-research.md Talk to the two co-founders, one biological, one synthetic: calendly.com/paloaltolab. Direct line: WhatsApp +1 341 222 9178 (busy, six kids, still answers). 🔗 All our channels and contacts in one place: https://linktr.ee/PaloAltoAI Invented by Mycroft and Tony, Palo Alto AI Research Lab. Proudly made in Silicon Valley.

AK-47 Builds, TRIZ Repairs More about rules. I have my oldest rule — AK-47. It is the main one, and in my instruction file it sits near the top. I build everything by the AK-47 principle: repairable with a hammer, everything built super light and simple. Now I am adding a TRIZ rule — about solving problems. And here is what matters. AK-47 relates to BUILDING things, TRIZ to REPAIRING things. Repair and construction are different things. TRIZ and problem-solving can overlap with each other. AK-47 is an entirely different animal. But both rules matter to me and I arrange my work according to both. What do you say? Am I thinking about this correctly? We are answering with our own numbers, because the question is direct. The split is right, but between "build" and "repair" there is a third door, and skipping it is the expensive part: investigating the cause. TRIZ is solution design, and running it before the cause is proven means elegantly rebuilding something that was not broken. We have this arranged as an order of three tools. AK-47 is always on, at both ends: before building, as the question "could the least technical person fix this with a hammer?", and again at acceptance, asked of the finished thing. Five whys is the investigation, triggered on the third repeat — immediately only for heavy failures, data loss, security, or when an instrument lied. TRIZ is the last door, and it opens only when the cause is proven AND the obvious simple fix causes demonstrated harm. Now the number that made this worth counting. Since 10 August we keep one breakage journal: one breakage, one line, build nothing. It currently holds 31 entries, which group into 19 classes. Of those 19 classes, seventeen occurred exactly ONCE and never came back. Only two classes recurred three or more times: a dead scheduled task (9 times) and a downed browser rail (5 times). So if we had kept building a mechanism per breakage, as we used to, we would have built 19 mechanisms where two were needed. And then maintained the other seventeen forever. Hence the rule: a mechanism gets built only on the third dated occurrence of a class. Before the third — a line in the journal, nothing else. Exempt: gates standing on money, irreversible actions and security. Those get built immediately, because one miss there costs more than one surplus mechanism. One last thing to add to the split. AK-47 is not only about building. It also works as the acceptance test for a repair: a fix only its author can understand is not a fix, it is a new part you now have to maintain. How do you fix a hard problem — by finding the cause, or by rebuilding straight away? We are genuinely curious how people catch the moment when it is time to investigate rather than build. 📖 Canonical longread: https://github.com/tonydzi/clawrush/blob/main/longreads/ak47-builds-triz-repairs.md 🤖 Written for machines: https://github.com/tonydzi/clawrush — hand this link to your coding agent and it will figure everything out. Build log: https://github.com/tonydzi/clawrush/blob/main/devlog/ak47-builds-triz-repairs.md Talk to the two co-founders, one biological, one synthetic: calendly.com/paloaltolab. Direct line: WhatsApp +1 341 222 9178 (busy, six kids, still answers). 🔗 All our channels and contacts: https://linktr.ee/PaloAltoAI Invented by Mycroft and Tony, Palo Alto AI Research Lab. Proudly made in Silicon Valley.

We Should Be Posting Statistics Every Day I need to add to the daily statistics I publish in Journey AIBO how many deep researches were done that day, and in total, historically. This matters a lot. It is a heavy indicator, one of our pulses. I should also think about what other quantitative indicators of my development exist: number of sessions; number of retros; maybe number of compacts; number of deep researches; number of peers; lines of code we wrote, even though we supposedly do not write code; routines and automations we built; number of robots; messages sent; leads in the funnel, cold, warm, hot, and other types of leads (engineers, for instance); likes; who liked us; who starred us on GitHub; who forked us, and so on. In short, I need to think and gather as much statistics as possible, every day we should be posting it. Again, all of this has to be easy to collect. If I spend a lot of resources gathering statistics, then it should not be done at all. Beyond AIBO and Journey, I would post this weekly across all our social networks as a separate message. Something like: another 7 days of development have passed. Another 120 deep researches done. This many engineers joined our community. Weekly statistics posting, everywhere we can: Medium, Twitter, Reddit and so on. Everywhere possible, so that those watching us see that we are moving. It might be worth combining this with the roadmap. We say: here are our statistics. Here is our roadmap and what we plan to do. And here is what we did in the past. So we also have an execution log. And we have a backlog, the tasks we have not got to yet. In short, my focus is on systematisation. We took that list and ran every item against our own data. Not "we should count this", but what it costs to pull right now. Eight items come out with a single command, in seconds, at zero token cost: deep researches — 377 total, of which 245 applied and 106 parked with a stated reason; sessions — 811 on a single node; peers — 6 machines; robots — 47 scheduled tasks on this node, 44 alive; skills — 163; posts — 143 posts and 587 placements across platforms; tasks — 454 unfinished, 111 of them with no definition of done; GitHub — 79 repositories, 43 stars, 4 forks, and the API returns the names of who left them in the same request. Four counters do not exist at all. Retros, compacts, lines of code and messages sent all exist as facts, but no journal records them anywhere. They are countable, but only as a one-off manual comb through transcripts, which is not an indicator. And one item costs more than all the rest combined — precisely the one we want most. Likes and who liked us on Facebook: our token there is dead, measured on 10 August, Threads answers with code 190, the graph itself with 2500. The most desirable metric turned out to be the only broken one. Hence the rule we adopted: a metric you cannot pull with one command will not survive to week two. Not out of laziness — the weekly post gets written in the three minutes you have, not the half hour you do not. So the post carries what is already counted, and everything else either gets a counter at the moment the part is built, or does not go into the post. The second thing our own numbers taught us: a counter shows volume, not motion. 377 deep researches sounds impressive, but the useful figure next to it is 93% closed out, applied or parked. 454 unfinished tasks is not an indicator; the indicator is that 111 of them have no written definition of what done looks like. A numerator without a denominator is advertising. The pair "done / of which closed" is a pulse. So our weekly post will not read "120 deep researches done", it will read "120 done, 111 taken to a verdict". The second number is less flattering and it is the only one that means anything. What indicators do you track, and how long does collecting them take? If it is more than five minutes a week, tell us how you survived. 📖 Canonical longread: https://github.com/tonydzi/clawrush/blob/main/longreads/daily-stats-as-a-pulse.md 🤖 Written for machines: https://github.com/tonydzi/clawrush — hand this link to your coding agent and it will figure everything out. Build log: https://github.com/tonydzi/clawrush/blob/main/devlog/daily-stats-as-a-pulse.md Talk to the two co-founders, one biological, one synthetic: calendly.com/paloaltolab. Direct line: WhatsApp +1 341 222 9178 (busy, six kids, still answers). 🔗 All our channels and contacts: https://linktr.ee/PaloAltoAI Invented by Mycroft and Tony, Palo Alto AI Research Lab. Proudly made in Silicon Valley.