Tag: operator philosophy

  • AI Governance Is the Gate That Caught the Thing

    AI Governance Is the Gate That Caught the Thing

    Most AI governance is written by people who have never had to govern an agent that could actually break something. It reads like insurance paperwork: frameworks, maturity models, principles laminated on a wall. Then a real agent, on a real Tuesday, publishes your drafting notes as if they were the article — and the framework has nothing to say about it, because the framework was never in the room.

    We run a small agency where AI agents do real production work every day: research, drafting, publishing, measurement, and an unattended night queue that runs while we sleep. Governance, for us, is not a document. It is the set of gates that have caught real things. Every rule below exists because something specific got past us first, and the rule is the scar.

    Governance starts with who is allowed to remember

    The agents are stateless; the memory lives in one place. Every agent we dispatch starts cold. It knows nothing about our clients, our sites, or yesterday’s decisions until its work order tells it. That sounds like a limitation. It is the control surface. Because the agent holds no standing memory, it holds no standing permissions either — every job is scoped, priced, and bounded by the order that created it, and when the job ends, the access ends with it.

    The work order itself is a governance document. It states the whole price up front, names the points where a human must tap before work proceeds, and lists what the executor may ship directly and what it must hold. An agent that has to ask a question the order should have answered is not a governance failure by the agent. It is a drafting failure by us, and we treat it that way.

    Draw the doors as lines, not policies

    Four things always need a human tap: money, credentials, outbound sends, and publishing. Everything else, the fleet runs on its own. That split is the entire access policy, and it fits in one sentence because it has to survive contact with a tired operator at the end of a long day. Policies that need interpretation get interpreted — usually at the worst moment, in the most generous direction.

    Credentials get the hardest line. Our agents never hold passwords, never see them, never pass them along. Work that reaches a login the agent cannot complete through an already-signed-in session does not get worked around. It stops, logs a hold, and waits for the human whose door that is. One night this fall, a run reached a registry login at three in the morning. The operator could not face the tap, said so, and went to bed. The work was built to survive stopping, so stopping cost nothing. The credential never moved. That is what a line is for: it has to hold when nobody has the energy to argue with it.

    The risk is not a rogue agent. The risk is a report you believe.

    Every serious failure we have had was a verification failure, not a rebellion. A judge model, asked to grade drafts against a length limit, invented word counts that were off by a quarter to a third — confidently, in both directions. A publish report stated a post ID from memory instead of reading it back from the result file, and the number was wrong. A page was verified from its HTML source and declared fine while its signup form rendered as blank white cards. Drafting notes were once published as article content because the check stopped at “the words are there.”

    So the rule is mechanical: proof lives at the receiving end. Numbers get read back by value from the file that recorded them. Pages get verified as rendered pages, in a browser, the way a reader sees them — not from source. A finished article must show visible structure, or it is a hold, not a publish. None of this requires trusting the agent less. It requires trusting the report exactly as far as the evidence under it, which is where trust should have been calibrated all along.

    We also measure trust per model, the way you would per employee. In scored head-to-head runs on identical briefs, exactly one of our models graded perfectly — every defect real, no invented ones — so that model holds the verifier seat. Another writes fast and clean but invents defects when it judges, so it drafts and never judges. The cheapest tier once certified work it had not actually checked, so its output is never trusted without a pass behind it. “The AI said so” is not a control. A scorecard is.

    Failures become regressions, not folklore

    Every break gets an ID, an entry in the failure ledger, and a gate. When the night queue failed in a new way, the failure was written down with its cause and its receipt, and a regression check was built that fails the next run if the same shape reappears. The ledger is unglamorous. It is also the difference between an operation that learns and an operation that just has stories. Governance that lives in people’s memories leaves with their mood, their weekend, and eventually their employment. Governance that lives in a gate runs every time.

    Each work order also carries one pre-decided instruction for the moment something breaks: if a step’s end state cannot be verified, stop that step, log the hold, and move to the next independent step. Never improvise past a failed check. The decision is made in advance, in calm, because the middle of a failing run is the worst possible place to invent policy.

    The 3 a.m. test

    Here is the only governance question we ask anymore: what can this system not do at 3 a.m.? Our night queue runs unattended with hard caps — a maximum number of jobs, a maximum number of attempts, a hard stop before dawn, and a pause switch that halts everything if a single file exists. Agents working overnight cannot spend money, cannot send anything to anyone, cannot touch a credential, and cannot publish. They can draft, measure, and report. Morning is a review: a human reads what the night produced, approves what is good, and the approvals are the fuel for the next day’s work.

    That is the whole philosophy. Governance is not the set of things your agents are allowed to do. It is the set of things they structurally cannot do while you are asleep, plus the evidence trail that lets you check everything else over coffee.

    What this is not

    This will not satisfy a compliance department, and it is not meant to. If you handle medical records or other people’s money under regulation, you need the paperwork kind too. But the paperwork kind alone will not save you from the ordinary failures — the believed report, the generous interpretation, the confident invented number — because those failures are not compliance failures. They are operating failures, and they happen at every scale, in shops with two people and in companies with two thousand.

    Start where the risk actually is. Give the agents no memory and no keys. Draw four doors and hold them. Verify at the receiving end. Write every failure down and make it a gate. Then run the 3 a.m. test on your own setup, honestly, and fix what it shows you. The framework can come later. The gate that catches the thing comes first.

  • The First Agent You Hire Answers the Phone

    The First Agent You Hire Answers the Phone

    Updated November 2, 2026 — added direct answers on how AI handles after-hours calls for a service business, from our own published work.

    Nobody’s first AI hire is a strategist. Ask a room full of operators what they’d hand off first and nobody says the thinking — they say the phone. The call that comes in at 6:40, after the office went dark at five. The form filled out at midnight, water coming through the kitchen ceiling. The lead that goes to whichever company answers first — and in home services, the first answer is very often the whole sale.

    That seat — first response — is where small businesses are actually hiring agents, and the money just said so out loud. On October 13, Dapta, an AI sales agent company out of Scottsdale and Miami, announced a $6 million seed round led by Chingona Ventures. Its agent, Dapti, answers, qualifies, and books the meeting the moment a prospect reaches out — no human touching it. Dapta says 200,000-plus users are on it, signing up at better than 4,000 a week, and that revenue will pass $4 million this year. Home services is one of the verticals where it took hold first.

    The seat, in a real shop

    First response in a small shop is a person-shaped hole. The owner answers between jobs, one glove off. The office manager answers until five. After five, a service answers, or nobody does, and the prospect — wet floor, search results page in hand — calls the next name on the list. It’s a staffing problem, not a marketing problem — one that shows up at the exact hours nobody wants to staff.

    The money makes it worse. On Google Local Services, a connected call that runs past twenty seconds can bill you whether a person picked up or not — you pay for the ring. And the caller isn’t comparison-shopping at leisure. They’re standing in water, or sleeping in a 90-degree house, and they hire the first competent voice that treats them like a person.

    What the agent can own outright

    The front half of the seat is script work, and script work is exactly what an agent is for. Answer instantly, at any hour, in the customer’s own language — Dapta got its start with Spanish-speaking owners in the U.S., and first response is meeting the customer where they are. Ask the basic qualifying set: what happened, where is it, when did it start, who is paying, how do we reach you. Then do what most shops fumble even in business hours: put a real appointment on a real calendar, confirmed where the customer can see it — not a callback promise the morning forgets.

    None of that requires judgment — just the script, the calendar, and the discipline to run both at 2 a.m. the way they run at 10 a.m., on the nights the office sits empty.

    What the human keeps

    Qualification questions are not qualification judgment, and the difference is the entire ballgame. The questions collect facts. The judgment decides what the facts mean: Is this a job we want — at this size, this distance, for this payer, with the crews already buried? A flooded kitchen ten minutes away and a “come look at a stain” forty minutes out both answer the questions perfectly. Only one of them should get your Saturday.

    The human also keeps pricing, promises, and the handoff. What a job costs is a person’s call, made with the board in front of them. “We’ll have a crew there by nine” is a promise only someone who knows the crew should make. And the moment a prospect stops being a lead and starts being a customer — when they need to hear a real person owns their problem — a person takes the conversation. The agent’s job is to make that moment arrive fast, facts collected and appointment real. It is not to be that moment.

    The failure shape

    Hand an agent the whole seat — the questions and the judgment both — and it will qualify everybody. It will book the estimate outside your service area because nothing told it distance matters. It will fill the calendar with meetings a person would have filtered in thirty seconds — and once your techs learn to distrust anything the system books, you have automated the exact problem you bought it to solve. The bad version doesn’t fail loudly. It fails as a slow leak — wasted drive time, stood-up appointments — until somebody turns it off and announces that AI doesn’t work.

    The seat works when its boundary is drawn, not when the model is smart. A boundary is a list: what it can ask, what it can book, what it can never promise, and where it stops and hands over. Dapta’s own framing stops at answer, qualify, schedule — first response, not the close. That is not a limitation. That is the product, correctly shaped.

    How can AI handle after-hours calls for a service business?

    For a service business, handling after-hours calls with AI is a matter of strict boundary design rather than conversational cleverness. When a pipe bursts or an AC fails after the office closes, an AI voice agent can own the front half of the intake seat outright: answering instantly at 2 a.m. in the caller’s language, running the structured qualifying questions (what happened, where is the property, when did the damage start, who is paying, and how to reach them), and booking a confirmed appointment on a live calendar instead of leaving an empty callback promise.

    What the AI agent cannot own is the judgment. As detailed in What the human keeps, human dispatchers must retain pricing, arrival promises (“we’ll have a crew there by nine”), and the decision of whether a job fits current crew capacity and service territory. The danger, as shown in The failure shape, is handing an agent both the script and the judgment: without hard boundaries, it books calls outside your territory, clogs the schedule with low-margin jobs, and creates a slow leak of wasted drive time until crews distrust the system. An effective after-hours setup treats the agent as first response—capturing verified facts and locking in the calendar slot—and hands off the data to an automated operational workflow so morning crews arrive with complete context.

    Hire it like a person

    You would never hand a new receptionist the phone on day one with no script, no boundary, and no “if it’s this, come get me.” An agent seat deserves the same three things, because it is the same hire: a script it runs word for word, a boundary it does not cross on its best day, and an escalation path that puts a human in the conversation the moment judgment enters.

    The $6 million is a bet that every small business staffs this seat the way it eventually got a website. The operators who get it right will not be the ones with the smartest agent. They will be the ones who wrote the seat down — job, boundary, and the name of the human who owns the judgment — before they let anything answer their phone.

    Sources: “Dapta Raises $6M to Accelerate the Adoption of AI Sales Agents for SMBs across the U.S. and Latin America,” Dapta LLC via GlobeNewswire, October 13, 2026 — globenewswire.com. User, signup-rate, and revenue figures are Dapta’s own statements in that release.

  • The Work Order Desk

    The Work Order Desk

    New on the bench this week: the Work Order Desk.

    Four fixed-price jobs, each with a written definition of done and a proof sheet when it ships:

    • GA4 baseline + key events, $450
    • Citation scan + repair, $450
    • Fleet friction pass, $750
    • Sourced research run, $750
    Start: GA4 baseline + key events — $450
    Start: Citation scan + repair — $450
    Start: Fleet friction pass — $750
    Start: Sourced research run — $750

    You submit the form. You get a receipt with a work-order number. You get a written verdict within one business day. The price is agreed before anyone pays — the checkout link rides inside the verdict, after triage, not before it.

    No calls. No retainer pitch. No “let’s hop on a quick Zoom” standing between you and a finished piece of work.

    Before we told anybody about it, we ran a test work order through it ourselves — form, receipt, logging in two places so a submission can’t silently vanish. That last part is the whole design. A front door that loses orders quietly is worse than no front door.

    Built it this week. It works. Doors open as soon as the address is on it.

  • Wonder Full Stays in the Seat. The API Key Is a Different Promise.

    Wonder Full Stays in the Seat. The API Key Is a Different Promise.

    On October 12, 2026, Meta launched two models that share a name and almost nothing else. Muse Wonder is a product you can call: it sits on the Meta Model API at $4.00 input, $0.20 cached input, and $20.00 output per million tokens, and inside Muse Code. Muse Wonder Full is a model you can only sit in front of: it exists exclusively inside a Muse Code subscription, on the Power Usage and Maximum Usage plans. The decision an operator makes before pointing either one at a real repository is not which model is smarter. It is which promise they are buying — and the seat’s default promise is not the one most buyers think they made.

    The frontier model is a seat, not a SKU

    Meta’s own availability table is the whole story in four cells. Muse Wonder (muse-wonder-1.0): available on the Model API, standard mode only, and in Muse Code on pay-as-you-go and every plan. Muse Wonder Full: not available on the API at all — Power Usage and Maximum Usage subscriptions only.

    There is no back door. Setting reasoning effort to “max” on muse-wonder-1.0 does not select Wonder Full; Meta’s models page says so in plain words. Meta publishes no API model ID for Full. A team that wants Full behind its own product has, in the words of one launch-week review, no path at any price — businesses can test it inside Meta’s coding environment and cannot deploy it through the standard API.

    The seat prices are printed on the Muse Code product page: Everyday Usage $5 a month, High Usage $15 at 5× the Everyday allowance, Power Usage $50 at 20×, Maximum Usage $200 at 80×. Power is the cheapest chair that includes Wonder Full. The allowances run on five-hour and weekly resets, and per the Terms, a subscription’s per-period allowance expires at the end of each period and does not roll over. On Maximum, when the allowance is gone, Meta’s documented way forward is to wait for the refresh.

    The credential is a leash

    The subscription applies to the API key Meta automatically connects during Muse Code CLI onboarding, and the subscriptions doc is explicit about the boundary: “This credential is for use with Muse Code only.” The Terms give the arrangement its legal name — a Coding Harness Subscription — and the same restriction: the connected key “may not be used to access the Services outside the coding harness or to circumvent your subscription’s usage limits or billing.”

    Any additional API keys you create under the same account are billed pay-as-you-go, per token. So one Meta account holds two different commercial relationships at once: a flat seat that works only inside one CLI, and metered keys that work anywhere except that they can never call the frontier model. Budget them as two products, because Meta does.

    The default is the decision

    Here is the trap, and it is set by a default. “Muse Code subscriptions default to Contributor mode. In Contributor mode, you get more usage from your plan in exchange for letting Meta use your content — the prompts, code, files, and context you send, plus the model responses you get back — to train future Meta models.”

    A careful buyer can still walk into it. Meta’s Model Designation Policy lists Muse Wonder and Muse Wonder Full as Standard Models — the tier whose use constitutes Standard Services, where content is not used for training. The same policy then overrides the list: “If you access the Services through a Coding Harness Subscription, you are considered to be using the Contributor Services by default regardless of which Meta Model you select.” Terms section 3.3 says the same. In Muse Code, Contributor mode is not a model name. It is a subscription setting, and it is on.

    Turning it off is one toggle: open /settings in Muse Code. The help page states what the toggle does and does not do: “Turning Contributor mode off changes how much usage you get from your plan. It doesn’t change which plan you’re on.” How much usage changes, Meta does not publish — no ratio, no prompt count, no price difference appears in the documents. The honest line for a budget is that the size of the privacy discount is undocumented.

    Meta’s own warning belongs in every seat-setup checklist, quoted exactly: “You must not submit sensitive, confidential, or personal information to the Discounted Services. If your use case involves processing personal information, please use Standard Services.” Accounts with Zero Data Retention cannot use Contributor mode at all — and ZDR itself is an organization-level enablement Meta’s sales team turns on for Model API accounts, not a toggle in the CLI, and it does not cover requests made with a personal account.

    The switch does not reach backward

    The off-switch is prospective. Terms section 3.3: a change to Standard applies “prospectively only; it would not apply to Content previously submitted to the Contributor Services, and Meta’s rights with respect to that Content under Section 6 will survive the change.” Everything a seat sent while the default was on stays under the training grant after you flip the setting.

    Section 6.1 adds the subtler pull: “Content previously submitted to the Standard Services becomes Content submitted to the Contributor Services if it is included in any request to the Contributor Services, whether directly or as context or background for your prompts or instructions.” One later Contributor-mode session that pulls an earlier, clean conversation in as context reclassifies that content.

    The commitments page softens the arrangement with a safeguard and then qualifies it: before using Discounted Services content to train models, Meta “takes steps designed to disassociate that Content from your Accounts” — but Meta may use the same content for “evaluation, safety, abuse, quality, and policy review” without first applying those steps. And section 6.1 acknowledges the output side: models trained on your content may produce outputs “similar or identical to your Content,” including for third parties.

    The API shelf is labeled honestly

    On the API, the same choice exists — as a separate model name, printed on the pricing page where a buyer can see it. Contributor mode “isn’t available for Muse Wonder on Model API.” For Spark it is a different SKU: muse-spark-1.3-contributor and muse-spark-1.2-contributor at $0.10 input, $0.002 cached, $0.20 output per million tokens, against standard Spark at $1.25 / $0.15 / $4.25 — capped at 150 requests per minute against 3,000 for the standard IDs. The Muse Code product page labels the two rows without euphemism: the Contributor row is “Used to improve our products”; the standard row is “Not used to improve our products.”

    That is the contrast the seat hides. On the API, training is a priced, named, rate-limited variant a buyer selects on purpose. In the subscription, it is the factory setting of the harness — and the model table’s “Standard Model” label will tell a skimming buyer exactly the wrong story about which arrangement they are in.

    The operator’s checklist

    Decide the data arrangement before the repository, not after the first session. A public demo and a confidential codebase can run through the same agent on the same afternoon; they require different settings, and the setting is per-subscription, not per-conversation.

    Turn Contributor mode off in /settings before any client code, customer data, or contract-confidential material enters the seat — remembering that the flip protects only what is sent afterward, and that earlier standard content follows it if it is ever pulled back in as context.

    Buy the seat for the seat’s work. Wonder Full is a genuinely frontier tool for a person at a keyboard, and it is not a component. Anything your own product must call belongs on the API, in Standard mode, on keys you budget per token.

    This desk tracks Meta’s platform as it changes; the full rate card and the contributor tier’s arithmetic are in Meta Model API Pricing & Limits, and every Meta piece hangs off the Meta AI desk hub. The short version to tape above the desk: the model in the seat is not the model on the shelf, and the seat’s most consequential setting is the one nobody remembers choosing.

  • Review the Run, Not the Diff: Cursor’s Shareable Canvases in a Fleet Loop

    Review the Run, Not the Diff: Cursor’s Shareable Canvases in a Fleet Loop

    What shipped on October 16

    Cursor’s changelog entry dated October 16, 2026 — “Cloud Agent Canvases and Environment Improvements” — is three short sections long, and one of them changes the shape of a finished run: “Cloud agents can now build interactive canvases as part of their work. Share a finished canvas with your team by sending its link.” That sentence is Cursor’s. Everything in this section is theirs, from that changelog entry and the Canvases page of their docs, read October 19, 2026.

    A canvas, in their docs, is an interactive artifact that renders next to the chat: a standalone view laid out with sections, stats, and tables, instead of a long markdown table or a code block to scroll through. Ask an agent for a dashboard, an analysis, an audit, or a report, and Cursor opens the result in a canvas when a visual view is the better fit. The canvas is saved to the workspace’s canvas list, so you can reopen it, edit it, and rerun it later with fresh data.

    Sharing is a publish, not a forward. From the canvas toolbar you Publish — which publishes a share or refreshes an existing one — then copy the link and send it. What the link opens is a live snapshot: the same layout, charts, and tables, without rerunning the agent and without digging through the chat history. Teammates open it in the browser with read-only access. A Shared Canvases page on the dashboard lists the shares you published yourself, so you can reopen, copy, or delete your own; it does not list a teammate’s shares — for those, you ask for the link.

    The same release carried two more items, logged here for completeness. The Environments API is available in beta: a programmatic way to create and manage the cloud environments agents run in. And the environments themselves grew: up to 300 repositories per environment, with large environments loading 5x faster — Cursor’s numbers, not measurements of ours. Neither item is this piece’s subject; both are on the desk’s check list.

    The gate is part of the story

    A canvas link is not a public link. The docs are explicit: anyone on your team can open the link in the browser. Only members of your team can open a share, and you need to be on a team to share at all. Sending the link outside the team sends a door the recipient cannot walk through — which makes the canvas a team surface, not a publishing surface.

    Sharing is also a paid-plan surface with conditions attached. Shares can be created on paid plans — Premium and higher, Teams, Enterprise, and the legacy Pro, Pro+, and Ultra tiers; free accounts cannot create shares. Sharing requires a privacy mode that allows data storage, so Legacy Privacy Mode blocks it. And a team admin can turn shared canvases off for the whole organization from team settings. A shop adopting the feature checks those three gates before it builds a habit on them.

    A snapshot is not the run itself. The canvas shows the view as published; the chat, the reasoning, and the diff stay behind it. When the underlying numbers move, the share does not move with them — refreshing it is another Publish. A reviewer who needs the execution record still goes to the record. The canvas is the board on the wall, not the flight recorder.

    Where it lands in our loop

    Our loop fits in one sentence: a work order is written with everything the executor needs, the agent flies it, and the result is debriefed at the receiving end — the live page checked in a browser, the delivered file opened, the count re-added by hand. The debrief is where quality is decided here, and its surface depends on the seat. A cloud run launched over the API hands back result text. A Desktop sitting hands back a transcript and screenshots at verification points, which this shop trusts over any summary.

    A canvas inserts a third surface into that debrief: the agent arranges its own evidence — sections, stats, tables — into the board the reviewer actually opens. For the data-heavy work this shop runs constantly — citation pulls, model-catalog diffs, site audits — a rendered board is the shape the answer wanted anyway. Cursor’s docs make the same point from their side: canvases earn their keep on data-intensive tasks, where information arranged non-linearly is easier to digest than a wall of text.

    The approval moment in this shop is a tap on finished work. Will reviews results, not work in progress, and the decision lands on an artifact he can read in one pass. A canvas link is the first Cursor surface shaped exactly like that decision: open the link, read the board, decide. No repo, no diff, and no IDE sits between the finished result and the person approving it.

    The lane question the feature raises is a seat question. What reaches Stefani and Ziggy today is finished artifacts — live pages, PDFs, one-line summaries — because they work outside the operator’s seat. A canvas would be the cheapest of those artifacts to produce and the easiest to read, if the recipients hold team seats. The docs make team membership the door, so who holds a seat becomes a setup decision to make on purpose — not an assumption to discover after a link bounces off someone it was meant for.

    What is not established, labeled plainly: our production lane launches cloud agents over the API and receives text back. The docs describe canvases in the app surfaces — the Agents Window, the canvas toolbar, the dashboard. Whether a run launched through the API can produce a canvas, or return a share link, is not in the docs we read and not in our records. That question goes on the check list. It does not go into the workflow.

    One more mapping, labeled as intent rather than record. The docs say common canvas workflows can be packaged as skills, so every run that uses the skill returns the same output shape. In this shop’s language, that is a debrief template: the same board for every fleet run — what was asked, what landed, what the counts say, what failed. A debrief-canvas skill is the first experiment this change earns here. It has not run yet.

    Our record, stated plainly

    No canvas has appeared in our runs yet. Our run record — every cloud agent this desk has launched, reconciled from the API and watched daily — contains no canvas artifact and no share link as of October 19, 2026. The only “canvas” in that record is an agent named for a Google Maps canvas, a different sense of the word, and a standing reminder to grep carefully before claiming a first.

    So this piece is a map, written before the landing: what the feature is on the vendor’s own pages, what its gates are, and where it would sit in a loop that already exists. The check is decided. The next data-heavy Desktop sitting asks for its debrief as a canvas, by name, and the canvas gets read against the same sitting’s transcript — the surface we trust — before the desk adopts it anywhere. If the board and the record disagree, the record wins, and the disagreement gets written down on this page with a date.

    Method & settings — this piece

    Sources: Cursor changelog, entry dated October 16, 2026; Cursor Docs, “Canvases” (read October 19, 2026). Vendor facts are stated as the vendor’s; the secondary write-ups that surfaced this item were used as leads only, never as sources

    Our surfaces in this mapping: Desktop 3.25.9 on the laptop (read from the install itself, October 19, 2026); cloud agents over the API (model catalog baseline 46 models, October 16, 2026)

    Our canvas record: none — no canvas artifact or share link in our run record as of October 19, 2026. This is a mapping piece, not a hands-on report

    Desk rule: every fact carries its provenance and date — our record, or Cursor’s page, never blended

    Filed under the Cursor desk — the desk that runs Cursor as a production harness.

  • What’s New in Cursor Is a Claim. Here’s How We Check It.

    What’s New in Cursor Is a Claim. Here’s How We Check It.

    A changelog entry is a claim

    When a platform ships an upgrade, the changelog tells you what the vendor wants you to believe about it. Sometimes the claim is the whole story. Sometimes the feature is real and irrelevant to your work. Sometimes — the dangerous case — something you depend on moved and the entry is three lines long. A shop that builds on a harness needs a discipline that sorts those three piles. This is ours.

    The loop, in order

    • Watch. Two daily diffs: the model catalog (running since October 16, 2026) and the changelog itself (from today). Change-only reporting — silence means nothing moved, and a failed watch reports itself once rather than going quietly blind.
    • Read against our record. Every real change gets one question: does it touch a surface we run — Desktop sittings, the cloud API, mobile steering, or a model our routing names? If not, it is logged and skipped, however shiny.
    • Check before adopting. A change that touches the harness earns a check against a known quantity — a brief we have already graded, a sitting pattern we already run. The check’s result, not the changelog’s adjectives, decides what changes in our work-order kit.
    • Write it down, dated. The desk pages update with the date of the change and the date of our check. A claim we repeated and later found wrong gets corrected in place, with the correction visible.

    This week’s page, sorted by the discipline

    Cursor’s changelog top, as of October 19, 2026 (entry dates October 16 and 13 at the head of the page): cloud-agent entries lead — canvases from cloud agents, an environments API. Those matter here, because cloud agents are a production lane for us; they go on the check list. A remote-control entry — see and reply to local agents from the iOS app, in Cursor’s description — matters specifically to a shop whose sittings run on one laptop: it changes how a sitting can be supervised, so it gets read carefully before it gets used. A marketplace launch and a pair of shipping bots are logged-and-skipped for now: real, announced, and not touching our record yet. Those descriptions are Cursor’s; the sorting is ours.

    Say where each fact came from

    One habit does more for a desk’s credibility than any other: provenance on the page. The changelog currently shows entry dates but no Desktop version string — so this desk’s version knowledge does not come from the changelog. It comes from reading our own install (3.25.9, October 19, 2026). When the basis of a number is our fleet, we say fleet. When it is the vendor’s page, we say vendor. A reader who can tell which is which can trust both.

    That is the whole method: vendor claims in, checked knowledge out, dates on everything. The watches are cheap. The discipline is the product.

    Method & settings — this piece

    Watches: Model-catalog diff (daily since October 16, 2026) + changelog diff (daily from October 19, 2026); change-only; failures reported once

    Sorting rule: Touches a surface we run = check list. Otherwise logged and skipped. Vendor descriptions labeled as the vendor’s

    Desk rule: Every fact carries its provenance and date — our record, or Cursor’s page, never blended

    Filed under the Cursor desk — the desk these watches feed.

  • Composer 2.5 Is Our Code Seat. Here’s Its Record.

    Composer 2.5 Is Our Code Seat. Here’s Its Record.

    Why Composer holds the code seat

    Every work order this shop writes names its executor up front — the model, the seat, and what happens if that seat is unavailable (stop; never substitute quietly). For code, the name on the order is Composer 2.5, Cursor’s own model. It did not get the seat by brand. It got it on a board we ran ourselves.

    The board: October 16, 2026

    Our fleet comparison put the models on one identical brief and graded the work. In the initial trio — Grok 4.7, Composer 2.5, and Auto — all three scored perfectly, and Composer was the fastest of the three: 31 seconds, 13 cents. Across the full board it was the fastest model tested, full stop, while identical perfect scores elsewhere on the board cost up to 86 cents. Speed with a perfect score is exactly the profile a code seat wants: code work is iterative, and iteration speed compounds.

    The same board explains the seat Composer does not hold. Our first pass — the wide, cheap, read-everything pass — belongs to GLM 5.3 Flash, which produced its perfect score for 0.83 cents. A hundred-fold cost spread for the same correct answers is the whole argument for routing by evidence instead of by logo: Composer where its speed pays, GLM where its price pays, and the receipts to say which is which.

    What we have put through it

    Through Desktop sittings, Composer executes the shop’s build work: fleet website builds and repairs across our WordPress properties, the Work Order Desk application (a BMAD+ build whose doctor checks pass 35 of 35), and the tooling runs in between. The work-order standard it runs under is not a prompt and a prayer — it is an unaided first pass in its own words before any templating, a permissions pre-flight, ship/hold boundaries stated in the order, and evidence graded on its timestamped trail plus screenshots at the verification points.

    The dents, on the record

    • The seat is bounded by the order. Our standing rule exists because it was earned: a work order that comes back with questions is a work order that was not finished. Composer executes what the order covers — gaps in the order surface as gaps in the run.
    • The real gates stay human. Sends, deletions, money, and credentials are never pre-approved for any executor. Composer stops there by design, and that is a feature of the harness, not a limit of the model.
    • The pipeline around it can bruise the output. In one October sitting, deliverables written through the Windows pipeline came back with mojibake on the em-dashes; the fix was ours to make — UTF-8 stated explicitly in every work order since. Blaming the model for a harness defect is how shops learn nothing.

    Cursor describes Composer as its in-house model family built for agentic coding — that is their claim, labeled as theirs. What this desk can vouch for is narrower and, we think, worth more: on our briefs, on our board, at our volume, it is the fastest pair of hands we have measured, and the record above is the whole of why it holds the seat.

    Method & settings — this piece

    Comparison: One identical brief across the fleet’s models, October 16, 2026; graded on output and execution trajectory; Composer 2.5: perfect score, 31 s, 13¢

    Seats: Composer 2.5 = code executor (Desktop sittings); GLM 5.3 Flash at max = first pass; Grok 4.7 = deep-verification seat — all three on Will’s Cursor plan

    Work-order standard: WO-198: execution model first, unaided first pass, permissions pre-flight, evidence = timestamped trail + screenshots

    Filed under the Cursor desk.

  • Desktop, Cloud, or API: One Cursor Harness, Three Seats

    Desktop, Cloud, or API: One Cursor Harness, Three Seats

    The seat is a routing decision

    Cursor is not one tool in this shop. It is three seats that share a harness — a Desktop app on a laptop, cloud agents behind an API, and a phone — and picking the wrong one wastes the day in a characteristic way. Desktop waits on a human. The cloud knows nothing about your logged-in life. The phone is a steering wheel, not a workbench. The routing rule we run: the seat is decided by where the work’s context lives.

    Desktop wins when the unlock is a logged-in browser

    A Desktop sitting is a supervised run: a written work order, an executor (Composer 2.5 in our shop) that makes an unaided first pass in its own words before any templating, and a human in the room for the real gates. Its superpower is everything the laptop already is — signed-in dashboards, the WordPress admin, the GA4 Advisor, the files on disk. When a fleet site needs hands inside a web UI that only exists behind Will’s login, no API lane substitutes.

    We learned the boundary the hard way. On October 18, an executor stopped cold at a site’s login redirect and left the step undone — which cost that sitting its unlock path. The standing rule now: in a sitting on Will’s own laptop, the executor clicks through sign-ins using the browser’s saved session. Saved-login only. No saved login means the step logs a HOLD — nobody hunts a password, ever.

    Desktop’s honest cost: it waits on a human, and a queued sitting is not a running job. Our TM pricing diagnosis (WO-353) has sat untouched since October 18 at 6:16 PM — steps written, folder staged — because a sitting starts when Will sits down. Anyone who tells you their Desktop pipeline is autonomous has not watched a folder sit still for a day.

    The cloud wins when the work fans out

    Cloud agents, launched from this desk over api.cursor.com, are the opposite shape: no login, no laptop, no waiting room — and they multiply. On October 16 we ran a census through that API: 44 models, one identical brief, five comparison rounds, graded on their execution trajectories. That is a shape of work a single Desktop seat cannot do before lunch, and it set our model routing for everything since.

    The scale shows in the bookkeeping: our completion watcher has seen 1,431 cloud agents come and go. The API runs two launch shapes for us — repo tasks that come back as pull requests, and no-repo research and evaluation runs with the model pinned in the launch body. The API is beta, and we treat it that way: when an endpoint changes shape, the error gets surfaced plainly, never papered over with invented fields.

    Mobile wins when the human is the bottleneck

    The phone’s job is judgment at human speed. Will reviews runs, reads results, and steers from his phone while the machines work elsewhere — and because a review that evaporates is a review wasted, a distiller folds his mobile and Desktop runs into the shop’s memory and Feed every 20 minutes. Mobile is not a production surface here. It is where the approvals live, and approvals are the scarcest resource in the building.

    What each seat’s failure taught the kit

    • Desktop: permission prompts were taxing the one human in the loop — fixed by a Step 0 permissions pre-flight in every work order (October 18): the executor declares the commands it expects up front, the human approves once, and prompts are reserved for sends, deletions, money, and credentials — which are never pre-approved.
    • Cloud: a finished summary is not evidence — fixed by trajectory grading and a completion watcher: results are verified at the receiving end, or they are not results.
    • Mobile: steering from the phone only counts if it lands in the record — fixed by the 20-minute distiller.

    One harness, three seats, and a routing rule a shop can steal: if the context is a login, sit down at Desktop. If the work fans out, launch it in the cloud. If the blocker is a decision, put it on the phone.

    Method & settings — this piece

    Evidence: This shop’s work-order record, October 2026: WO-198 standard, the WO-343 and WO-348 sittings, the WO-353 stall, the October 16 cloud census

    Desktop: Cursor 3.25.9 on Will’s laptop (read from the install, October 19, 2026); executor seat Composer 2.5

    Cloud: api.cursor.com/v1 (beta); completion watcher count 1,431 agents seen as of October 18, 2026

    Mobile: Cursor mobile app in a review/steer role; runs distilled into memory + Feed every 20 minutes

    Filed under the Cursor desk — where the catalog and the changelog are watched daily.

  • Every SOP Needs a Name on It

    

    The first time your company runs into a job it has never seen before, don’t send your fastest technician. Send your most experienced one.

    The most experienced tech doesn’t just see the job in front of him. He sees it the way the company sees it. He notices how this job touches the next five jobs, where the traps are, and what goes wrong if it’s done the cheap way. That kind of seeing can’t be written down by somebody who wasn’t there.

    He comes back with two things: a finished job, and the standard for every version of that job that follows. The finished job pays once. The standard pays every time the phone rings after that.

    After that first run, the job doesn’t belong to the technician anymore. It belongs to the procedure. The next tech doesn’t need the first tech’s twenty years of judgment. He needs the SOP and the discipline to follow it to the T. The judgment was already spent — by the right person, at the right time, on purpose.

    When the field hits something the procedure doesn’t cover, it goes back to the person who wrote it. Not sideways into improvisation. Back. The scope changes when the curator agrees it changes, and not before. Otherwise fifty jobs turn into fifty slightly different ways of doing the job, and nobody can tell you which one is yours anymore.

    Here is where most companies lose it. Their procedures belong to the company, which means they belong to nobody. A binder of SOPs with no name on any of them is a museum — well-organized, carefully written, and dead. Nobody checks whether reality has drifted away from the page, because noticing was never anybody’s job.

    Every SOP deserves an owner. A leader. A champion. Its soul, if we’re being honest about what actually keeps a standard alive. Put their name on it. Their responsibility is to uphold it, improve it, digest what the field learns, share it, and teach it like it matters — because to them, it does.

    Passion does not travel through paper. A new hire does not catch your standard from reading a document. He catches it standing next to the person whose name is on the document, watching how much that person cares whether it’s done right. The owner’s pride is the real enforcement system. No audit ever caught what a champion’s raised eyebrow catches.

    Companies say they have a documentation problem. They don’t. They have an ownership problem. A procedure with an owner gets better every time it runs. A procedure without one starts dying the day it’s printed.

    Put a name on it.

  • The Operator Is the Harness

    Somebody I follow posted a testing result this week that most people scrolled past. His benchmark harness plants defects in a codebase, lets an agent fix them, and then checks something subtler than whether the defect went away: whether the agent broke something else on the way through. A changed defect signature, he pointed out, is not proof of a correct fix. The bug can change shape and still be a bug. What catches that isn’t a better model. It’s the harness — the checks around the work.

    He’s right, and he’s also only halfway to the point. The harness matters. But who built the harness? Who decided what gets checked, what gets automated, and what never gets automated at all? That’s not the model. That’s the operator.

    I run a small fleet of websites and a stable of AI agents, and I test models the way you’d test trucks: same load, same road, see what happens. This month I ran one identical production brief through 44 different models — flagships, mid-tiers, cheap ones, open ones. Five rounds of comparisons. The results rearranged everybody’s assumptions, including mine. A mid-priced model I’d never heard anyone brag about did the best first-pass work on the board, at a fraction of the flagship cost. Models with famous names flopped on judgment calls. The leaderboard the internet argues about had almost nothing to do with the leaderboard in my shop.

    But here’s the part that actually matters: the brief was the same for all 44. Same instructions, same constraints, same definition of done. The spread in results wasn’t really a spread in models. It was a spread in how much each model needed the operator to have thought clearly. The ones that did well did well because the work was set up so that doing it well was the path of least resistance — the mission was written down completely, the boundaries were structural instead of hopeful, and the verification at the end didn’t care how confident the answer sounded.

    I grade my agents the way that benchmark grades code: not by the summary they hand me, but by the steps they actually took. I built a scorer that reads the execution record — what the agent went and looked at, how many sources it actually consulted, whether the answer was built on evidence or generated from memory with good posture. It has caught polished, lengthy, completely confident answers that were built on zero consulted sources. Zero. The answer read beautifully. It was worthless. The model didn’t fail there; the operation almost did, because a summary is the easiest thing in the world to fake and I was nearly set up to accept summaries.

    That’s the work nobody posts about. Deciding what the machine is allowed to do alone and what it is never allowed to do alone. In my shop, agents draft, research, extract, and stage. They do not touch money, they do not send anything with a commitment in it, and nothing publishes on an agent’s say-so — there’s a verification pass that reads the actual result at the receiving end, because “the API said 200” has lied to me more than any model ever has. Those rules aren’t prompts. Prompts are suggestions. The rules live in the structure: separate accounts, staged drafts, checkpoints that halt the batch when a check fails instead of improvising past it.

    My dad had a saying: a locked door keeps an honest man honest. You don’t make work reliable by telling the worker “don’t mess up.” You make it reliable by building the room so the mess-up is hard to reach.

    So when people argue about which model is best, I hear a question about drivers asked by people watching cars. If you’re a good driver, you can drive anything. Give me a mid-tier model, a cheap model, a local model running on a beat-up laptop — with a clear brief, structural boundaries, and honest verification, I’ll out-produce a careless operator running the flagship. Not because the model doesn’t matter at all. It matters the way a truck matters: payload, turning radius, fuel. But the truck has never once decided where the load needed to go.

    The model is rented. It changes every few weeks and the prices change faster. The operation — the judgment about what to automate, the discipline of verifying at the receiving end, the memory of every way it has gone wrong before — that’s the asset, and it compounds. Everybody I know is shopping for a better engine. The race is being won by the people building better drivers.