Pinned Tweet
I am Bruno. I build the AI operating system my own work runs on, and build the same inside expert firms.
A listener on my team chat acknowledged 40 messages in a median 8.5 seconds, with no model in it. An alert gate passed 7 of its first 24 alerts to me.
Every 3 days, a review reads the moments I had to step in. Its first run read 521 items, counted 101 interventions and proposed 8 changes; all 8 were applied that day.
I post failures too: one script logged 428 refusals and still reported success to its scheduler.
If you build agents inside a real business, compare notes with me.
A list on my phone shows what is waiting on me. A script rebuilds it every 5 minutes.
From 12:29 on October 24 to 23:10 on October 25, about 35 hours, every rebuild froze on one line: a text-cleaning regex with a repeat inside a repeat. On a long draft it slowed exponentially, and the time limit ended each pass before it published.
The list had stopped changing, and nothing said so.
The fix: a plain pattern that cleans the same text in no measurable time, and a watcher with no model that restarts a stuck rebuild and tells me only if that fails.
A stale screen looks exactly like a quiet day.
Telling me a request had arrived used to be a job for the agent run itself, so a long job could stay silent for a while.
On October 14 I moved that step into the listener script that starts the runs. The moment it sees my message, it replies "Got it" with the time and whether a run is starting or the request is queued. No model involved.
October 14 to 18: 40 acknowledgments. Median 8.5 seconds after I typed, 38 of the 40 within a minute, the slowest 2 minutes.
The cheap, certain step belongs in the script. The model keeps the work.
Terminal X calls it memory debt: when senior investors leave, a firm keeps the documents and loses the reasoning.
Its engineers spend weeks on site turning trusted memos into a versioned record per desk: past analyses, committee decisions, house views. An Eval Agent grades every output against a 54-criterion rubric, and each fail becomes a new instruction or test case. The company reports 88.6% agreement with the senior reviewer across 500 scored judgments.
My read: measure agreement with your best reviewer before you measure speed. And the record has to belong to the firm, or the debt moves to the vendor.
My agents and a second model read the same rules from 2 files. A small script generates the second model's copy from mine, with no model involved.
The copy stopped updating twice when my file outgrew a size limit in my own script. On October 14 I removed that limit. The script now raises the document budget as needed and runs after each source change and every 15 minutes.
October 14 to 19: 541 runs, 20 rebuilds, 0 failures. It raised the budget once. The latest rebuild landed 0.7 seconds after my file changed.
A fixed limit in a sync script is a stall waiting for the file to grow.
Anthropic reports how work changed inside its own company. By August, the agents its employees directed worked 6 times as many hours as the employees. About 80% of interactive session time was spent idle, waiting for a person.
Human work moved up a level. Meta-work (specs for multi-agent runs, one agent reviewing another, pipeline monitors) rose from 10% of sessions to 22%. Standing instructions for agents grew from a few hundred to 8,500 in a year.
My read: the scarce input is now the reviewer's attention. The first run of a review I built over my own setup counted 45 waits for my approval in 7 days.
Back from Paris: 3 hours with the presidents of JDM Technology Group's companies.
The question: when every competitor has the same models, what sets you apart?
The answer the room landed on: the system you build around them, and the brain that holds what your company knows.
At 1:20 a.m. on October 13, one of my project folders held 395 files at its top level, 118 of them superseded versions. I never delete anything, so every version was safe. I still could not find the current one.
At 1:24 my agent finished moving 417 items into one archive folder. The visible top level now holds the 2 files my routines read, the archive, and one folder with only the latest version of each deliverable.
A script with no model keeps that folder current: file patterns, newest non-superseded match wins, run after every agent session. It covers 21 of my folders now.
Keeping every version and finding the right one are separate problems.
A Sullivan & Cromwell partner built an agreement review tool himself, as a single-user prototype in Codex. OpenAI then helped make it work for many lawyers at once. It uses firm precedents and playbooks and returns a memo and proposed tracked changes for a lawyer to review.
At Benefit Street Partners, a portfolio manager built his own credit agreement tool from law-firm memos: about 20 minutes for a first pass, then an hour or more of human review.
My read: the person who owns the judgment should build version one, from sources they already trust. Making it work for colleagues comes second.
Who built the first version of your tool?
My phone lost voice notes on 2 October. The recorder finished cleanly, the save failed, and the phone deleted its only temporary copy.
The save step pointed into another app's storage, and that app had updated itself early that morning.
I moved saving to the phone's own folder, with a small bridge copying each recording to my Mac. A watchdog with no model in it checks the route every 2 minutes. In its drill it went red after 12 minutes and cleared 2 minutes after the planted file was removed.
Where do your silent failures hide?
Microsoft's Azure Networking team built an agent that resolves production network incidents on its own. What I would copy from their write-up is the wrapper.
It has no powerful account. It acts as the engineer who invoked it, and where a service identity is unavoidable, the narrower of the two applies.
Diagnostics run freely. Anything that changes production waits for a human, and that stop lives in the execution engine's code, since a prompt can guide behavior but cannot enforce a permission. Skipping it is earned per procedure and per action type.
Where does the write gate of your agent live: in code, or in its instructions?
In Paris today. This afternoon: a 3-hour, hands-on AI workshop with the presidents of JDM Technology Group's companies.
The question: when every competitor has the same models, what makes your advantage compound?
My answer: the system you build around them.
I gave a chat listener of mine one alert: a message "has waited 10 minutes without an answer."
The rule behind that sentence tested one thing: whether the message was still not marked done 10 minutes after I sent it. Not whether a run was working on it, and not whether the thread already held a reply.
On its first afternoon the 5 jobs took 13.6 to 31.9 minutes, so all 5 crossed the line.
The wording claimed something the test did not measure. Now: after 3 minutes with nothing posted, one status line; after 5 minutes with no run at all, the listener starts one itself.
Asana's browser agent paid full price for its own memory. It cached the fixed instructions but resent the growing page history on every call, and it trimmed that history at nearly every step, which kept it from ever being reused.
The fix: cache the history too, let screenshots pile up to 20 before cutting back, and give the history more room. On the same model, estimated cost per run fell from at least $36.21 to $1.24. With more room, one model went from 3 of 18 runs producing an answer to 18 of 18.
My check before swapping models now: is my own context tidying defeating the cache?
I broke my agents' file links with one sentence.
On 30 September I added it to the instruction file they all read: write every file link with angle brackets around the path, so paths with spaces stay clickable.
Over the next 9 days my desktop app's log recorded 218 file lookups it could not resolve. All 218 carried the brackets as part of the file name. The 20 hours of log before that sentence hold none.
On 9 October an agent session read the log, found the pattern and rewrote the rule.
The agents had done exactly what I told them. The log named the cause from the first day; nobody had read it.
Two doc fixes from Microsoft's new Agent Experience playbook:
Release notes used release-1.22.md. An agent seeking 1.22.2 assumed it had what it needed: none of the 4 runs that read it reached the 1.22.2 page. After a rename to release-1.22.0.md, 4 of 5 did.
A tip gave the exact CLI upgrade command. No run used it. After a warning that updating package.json by hand alone breaks the build replaced the tip, and the migration guide was rewritten, every run used the CLI.
Their reading: the agent "needed its existing plan invalidated." For skills and tool descriptions I take the same rule: say what fails.
My agents' effort check stayed green while 58 runs of a new fast lane recorded medium.
My settings file specified maximum reasoning effort. On 28 September I added the fast lane to start runs from the command line. By 3 October, all 58 had recorded medium. The check only read the setting.
A 2-run probe settled it: the same command line recorded medium without an explicit effort flag and max with it, 3 seconds apart.
One flag in the launcher fixed it. My nightly sweep now fails any launcher whose command line lacks the flag.
Process Zero, the method Chatham Financial published for redesigning its own work, accepts "no AI at all" as an answer.
The method: name the output, strip the process to its essential inputs, redesign the path between them, then choose the technology.
They keep watching output quality, unnecessary inputs or steps creeping back in, and whether the output is still the right one.
I would make each step added after launch carry 2 fields: why it exists and when to check it again.
How much of a nightly full backup is the same bytes saved again? I measured mine on 2 October.
31 nightly copies of my agent workspace, listed without extracting them: 754.2 GiB of files between them. Estimated from those listings, the first copy plus each night's net new content would take 28.6 GiB. That is 3.8%.
The odd part: 10,813 files had a new timestamp and the same size. I hashed 300 of them in two archives, and 299 were byte-identical.
I have not found what re-stamps them. An incremental copy that trusts timestamps would save every one again, so that question comes first.
Cresta's engineering lead on building agents: go too deterministic and you create "a giant decision tree."
Cresta built Conductor, an agent that builds other agents, on the Claude Agent SDK. From Anthropic's write-up:
Conductor turns requirements and edge cases captured during a build into tests.
When a new Claude model launches, Cresta reruns the same tasks with the same scoring before anyone commits to the change.
The team puts the initial build at about 20% of the effort.
The order I like: name the few workflows that must work every time, then write each rule and its test in the same sitting.
