Volume I · No. 02
By James Mason · Boulder, Colorado
24 April 2026

Friday Field Notes.

02
Issue two

What's worth paying attention to in AI this week, for people running their business.

Hey from Boulder.

Last Friday I wrote about Shopify wiring itself into the agent layer. This week Salesforce shipped Headless 360 and made the same architectural move. Two of the largest B2B platforms in the world, both re-architecting around agents instead of humans, inside the same month. That's a pattern, not a coincidence.

The work above the platform is changing shape. It used to be production: build the page, configure the screen, ship the dashboard. It's becoming orchestration: run the system that decides which pages, screens, and dashboards happen, for which customer, at which moment. Different muscle. Same client. The orchestration tier is the layer that survives. The work below it is what gets absorbed. Operators above the platform have about twelve months to make that switch before the price compresses out from under them.

This issue: what Salesforce going headless really did, four things I shipped this week that say where I think this goes, and a daily-plan agent I built for a client that any operator can copy this weekend.

In this edition Contents · IV.24.26
  1. Salesforce went headless. The work above the platform just changed shape.§ 01
  2. What I shipped this week, and why it matters for where this goes§ 02
  3. A daily-plan agent I built for a client. You can copy it this weekend.§ 03
  4. Three more things from the week§ 04
  5. The 90-day calendar test. Did your agent clear meetings, or add them?§ 05
01
Top of mind
The work above the platform just changed shape

Salesforce went headless. Now what?

What happened

This week Salesforce shipped Headless 360. The pitch reads like a feature drop. APIs first, the UI as a thin shell, agents treated as primary users. It isn't a feature drop. It's the second platform giant this month re-architecting around agents instead of humans. I covered Shopify making the same move in last Friday's issue. Different surface, same direction.

The architectural argument is the load-bearing one. When agents use a platform 100x more than people do, designing the interface for human eyes is backwards. The data, the endpoints, the action surface have to be machine-legible first. The chrome on top is decoration, and decoration is the first thing the platform stops paying for.

Why this matters more than another platform launch

Most weeks, a platform announcement is just news. Two giants making the same architectural choice in the same month, in public, with their pricing model attached, is a pattern. The rest of the week added more of it. OpenAI shipped workspace agents into ChatGPT. Anthropic put Managed Agents Memory into public beta. GPT-5.5 landed. Every announcement points the same direction: the platforms ship the pattern in days, and the layer above them, the agencies and operators and managers who sell into the platform, has not figured out what their job is yet.

The platform going headless doesn't just change the platform. It transforms the work that used to happen above it. If your job was to click through Salesforce, configure the screen, design the page, set up the dashboard, you are now competing with a free agent that does that work for pennies. The seat-priced layer above the platform is the layer most exposed.

The shift

The job above the platform stops being production. It starts being orchestration. Less "I build the dashboard for this customer" and more "I run the system that decides which dashboard each customer sees, when, and what action it triggers." Same client. Different shape of business.

Two questions to run on any work your team owns right now. Who consumes the output? And what are they actually paying for? If the answer is "a person, sitting in front of a screen my team built, paying for time or seats," the price is on a clock. If the answer is "an outcome the agent fleet can't produce without my system above it," the price holds. The orchestration tier is the second answer.

What to do this week

Pick one recurring workflow your team runs that touches Salesforce, HubSpot, QuickBooks, Shopify, or Notion. The kind a person on your team does every Tuesday. Ask one question: did I design this so a person clicks through it, or so an agent reads the state, decides what to do, and acts on it? If the answer is "a person clicks through," that workflow is on a twelve-month clock. Build the orchestration tier above it.

Where in your team's week is there a recurring decision an agent could read, run, and report back on, while your people do the work only they can do? That's the seam. That's where the next year of your business lives.

02
What I shipped this week
Four pieces of work that say where I think this goes

If the work above the platform is changing, I'd better be the one building it.

1. I rebuilt my own operating system. The enforcement layer is the load-bearing part.

This week I refactored my entire personal Claude setup. Six layers (identity, operating, state, knowledge, capabilities, memory), thin routers at every directory boundary, single-home rule for every file, ownership tags in YAML frontmatter so duplication can't quietly creep back in. I retired two foundational documents I'd been working from for months. I archived 33 plugin skills, 38 agents, and 15 plans. The active namespace dropped to roughly half what it was.

The reason matters more than the result. Content isn't the hard part of building a personal or team OS. The hard part is the enforcement layer, the small set of mechanisms that keep the system organized as it grows. Without enforcement, an OS becomes a graveyard of well-meaning documents in eight months. With enforcement, it composes. Mine is five things: thin routers at every boundary, the single-home rule, `job:` frontmatter on specialized files, cadence separation, and a settled-decisions log so I stop relitigating things I already decided. None of these are clever. They're load-bearing because they're enforced, not because they're elegant.

I'm writing this up as a longer field piece next week. The argument: enforcement isn't discipline. It's exposed seams.

2. I built a service-as-software pipeline for a client. The numbers say something.

I had a content migration job that, done by hand, would have been roughly 17 hours of cleanup, formatting, and validation across about 100 articles. I built a Claude-orchestrated pipeline instead. Skills for parsing source documents, normalizing headings, flagging missing metadata, and a 41-check validation rubric every article had to pass before it shipped. Total build time: 5 hours. Once it was running, a full corpus rebuild ran in under 60 seconds.

The number that matters isn't the speedup. It's that roughly 70 percent of what I built transfers directly to the next data transformation engagement. The skills, the rubric, the pipeline shape, all reusable across the next client of the same shape. Hourly billing is the wrong shape for this work. The right shape is outcome-based, and the only honest version of that is "you pay for the result, I keep the system." That's the bet on top of which the rest of Nobo gets built.

3. I started building Ciarán, my chief-of-staff agent.

Ciarán isn't a chatbot. It's a peer agent. Distinct voice, separable architecture, four mechanisms that force me past the comfortable-productive trap when I'm about to spend a sales day reorganizing my skills directory instead of selling. I locked the identity spec this week. Phase 2 starts next week: actual system prompt, actual Python, actual schedule. The first version that talks back is two weeks out.

This is the build-in-public bet. If I'm telling operators to build agent-grade systems for their work, I should be doing it for mine first. Ciarán is the system the system runs on.

4. I sketched the Agentic-First Knowledge OS.

I've been turning over the question of what knowledge work looks like when the agent is the primary reader. Not "ChatGPT with a sidebar over your Notion." Something different: a small operator-owned set of files, structured so an agent can read them, act on them, and write back. Vertical-specific operator packages on top. The horizontal piece is small enough I can ship a v0 in a weekend and use it for 30 days.

I'm writing about it on purpose, before I've decided whether it ships. If you've ever wished your knowledge system could think with you instead of just sit there, you're in the room I'm trying to build for.

03
Build this week
A two-hour build, then 30 seconds a day

A daily-plan agent that actually plans your day.

I built this for a client. It's running every morning.

One of the operators I work with had the same broken 9am loop most teams run. Open the task tool, eyeball the calendar, mentally subtract meetings, pick something to work on. It cost him 20 to 40 minutes a morning, picked the wrong thing half the time, and three meetings later the priority he'd committed to was untouched. We replaced it with a daily-plan agent that runs the loop in 30 seconds and asks him better questions than he was asking himself.

It pulls today's tasks, checks his calendar, calculates real available time, surfaces the edge cases through quick chat prompts, then drops a tiered, time-blocked plan into the surface he already works in. Not an email he'll skim. The plan, in the chat where the rest of his day already lives.

First build took us two to three hours. Every morning after that takes 30 seconds of his attention, and the 20-minute decision is gone. Two weeks in, the capacity number was wrong (it always is), the modal questions surfaced two recurring categories of edge case he'd never named, and the plan started getting better than the one he was making by feel. The system runs. He runs his day.

I'm sharing the full build below. You can stand it up this weekend.

  1. Why this exists. The morning planning loop most teams run badly: open task tool, eyeball calendar, mentally subtract meetings, pick what to do. Costs 20-40 minutes, picks the wrong thing half the time. The agent does it in 30 seconds and asks better questions than you would have.
  2. Prereqs. Claude Code or a Managed Agent. MCP connectors for your task system (ClickUp, Asana, Linear, or Notion) and Google Calendar. A capacity number. Default to 6.5 productive hours per workday and adjust after a week of data.
  3. Pull today's tasks. Filter for assignee = you, due ≤ today, status ≠ done. If your task system's API caps the filter response, do a two-phase fetch: first pull the filtered list with IDs and due dates, then fetch full details for the top 20 by priority. Caps the context so a 60-task backlog doesn't blow the agent up.
  4. Pull today's calendar. Today's events from Google Calendar. Sum the duration of meetings and any focus blocks already booked. Skip working-location events ("Home"). They aren't meetings.
  5. Capacity math.
    available = daily_capacity − already_booked − buffer
    # default: 6.5 − sum(meetings) − 1.0
    If available is zero or negative, it's a zero-capacity day. Don't skip the plan. Flag the top one or two non-negotiables as "if time permits" and move on.
  6. Edge-case modals. Three things the agent should never assume on. Personal blocks (gym, errand, school pickup): fully blocked, or available for light work? Tasks in review: quick five-minute reads, or real work that should fight for capacity? Tasks with no estimate or already over their estimate: what's the realistic remaining? Each one becomes a quick chat prompt: yes, no, skip. This is the part everyone leaves out. It's also the part that turns the plan from "the agent's best guess" into "what I actually said."
  7. Tier the work. Ordered, not just listed.
    Tier 1: non-negotiable. Overdue or due today.
    Tier 2: high priority. Marked urgent or high.
    Tier 3: large focus blocks. 7+ hours, schedule in 3+ hour blocks.
    Tier 4: small batches. ≤1 hour each, group into one slot.
    Ad-hoc reviews. Grouped, no capacity allocated.
    Walk the list, allocate min(remaining_hours, available_hours), mark each task "complete today" or "log Xh today," subtract from capacity, stop when the bucket is empty.
  8. Present and log. Drop the plan into the conversation, time-blocked, rounded to 15 minutes, mapped around the meetings. Append a one-line CSV log of what was planned. A week from now you can open the log and see where you drift between planned and done. That's the data the agent gets better on.
  9. What to schedule it on. Daily, 9am local time, weekday only. Check the calendar for an all-day OOO event before doing anything else. Don't make a plan on a PTO day.
  10. What to expect after a week. The capacity number is wrong. Probably too high. Adjust. The real win is the modal step. By Friday you'll notice the agent asking the same two or three questions every morning. That means there are two or three categories of edge case in your week you've never named explicitly. Name them, and you're not making those decisions cold anymore.

Why it works

The mechanical work, pulling tasks, summing meetings, doing the capacity math, runs in 30 seconds. The judgment calls, the ones only you can make about your week, get surfaced as quick yes/no/skip questions. By the time the plan is written, every assumption that mattered came from you. The agent just stopped you from making them cold.

Why it compounds

The CSV log is the whole point. Every morning a plan goes in, every evening reality lands somewhere different. A week of that data is a map of where your sense of your own week is wrong. The "two-hour" task that's always four. The Tuesday meetings that always run long. The in-review tasks that always come back the same day. Read the log on Friday, adjust the capacity number, add a tier rule. The plan next Monday is better than the plan today, because the data is yours.

Want me to build it for you? Hit reply.

04
Also this week
One thing to watch, one thing to read, one thing that's just beautiful

Three more things worth your minute.

No. 01 · Beautiful · IV.24@zan2434

Flipbook. Every pixel streamed live from a model.

This is the coolest thing I saw this week that has nothing to do with my business. Flipbook generates entirely live, frame by frame, from a model. No pre-rendered assets, no canned animations, just pixels coming out of inference in real time. Watch the demo. Notice the moment your brain registers that what you're looking at didn't exist a millisecond ago. That's the texture the next generation of interfaces is going to have. Static screens are going to feel old by the end of the year.

See the original
No. 02 · Continuity · IV.24From issue 01

Last week I said it was an operating system, not a chatbot. This week the platforms agreed.

Issue 01 made the argument that the AI thing your business needs is a system, not another tool. Seven days later, two of the largest B2B platforms in the world re-architected themselves around exactly that idea. The seat as the unit of value is over. The operating system above the platform is the thing worth building. I'll keep saying this until the people who sell on top of these platforms move first instead of last.

Re-read issue 01
No. 03 · Coming next week · IV.25Field piece

The enforcement layer most operating-system writeups skip.

Working title: The five things that keep an OS from becoming a graveyard. Argument: most "Team OS" content is a content map. The interesting question is what stops the content from rotting. Five mechanisms make the difference: thin routers, single-home rule, ownership tags, cadence separation, settled-decisions log. None of them are clever. All of them are load-bearing. Drops next week.

Send me a copy when it drops
§ 05 · One more thing

The 90-day calendar test.

Most agent and "AI assistant" deployments fail one test. They get bolted on top of everything you already do. You add the agent, the agent gives you outputs, you schedule a meeting to review the outputs, and now your week has a new recurring 30-minute slot you didn't have before. The agent saved you nothing. The calendar got worse.

The bar for a real chief-of-staff agent, or any orchestration-tier system, is the inverse. It should eat the meetings whose only purpose was coordinating the work, not pile new ones on top.

Here's the test. Imagine 90 days from now your agent is fully running. Open your calendar. The status meeting that exists because nobody trusts the system to update itself, gone. The Tuesday "let's just sync on this," gone. The 30-minute briefing where someone reads you the dashboard, gone. The recurring review where you hand-walk the team through the same numbers, gone.

If those meetings are still on the calendar in 90 days, you didn't build a system. You bought a chatbot.

The orchestration tier is what makes the meetings disappear. The agent doesn't just produce the report. It produces the report, posts it, flags what needs attention, schedules the action, and writes back to the system of record. Coordination disappears because coordination was never the work. It was the friction of nobody trusting the system enough to let it run.

Look at your calendar in 90 days. If it isn't measurably clearer, you didn't build the orchestration tier. You bought another tool.

Filed under · Operating principles

Reply and tell me what you're building.

Or what's stuck. Or which of the platforms above you sell on top of and what it's doing to your week. I read every one.

Office hours are open Thursday, 10am to noon, at Rayback Collective. No agenda, no pitch, just show up.

Reply to this issue
Next Friday · in your inbox

Get the next dispatch.

Weekly field notes every Friday. What's worth paying attention to in AI this week, for people running their business.

One issue a week. Unsubscribe in one click.
James,
Boulder.
See you next Friday
Filed 24 April 2026
from Boulder, Colorado