A shift in what I’m writing about, and the assumptions I’m carrying across.

The push that stops

Earlier this month my personal-assistant workspace published the previous post on this blog. It drafted the prose, drew the diagrams, waited for me to read them, copied the Markdown and the images into the blog repo, committed, pushed — and then stopped.

It stopped because the harness tells it to. Deploying the live site is explicitly out of scope: the repository lives on GitHub, the site is served by nginx on a VPS somewhere else, and nothing in the workspace is permitted to touch that step. I do it by hand. Afterwards I confirm the URL is live, and only then — after a second explicit confirmation — does the LinkedIn share go out.

That stop is not a missing feature I haven’t gotten around to. It is one of the most deliberate lines in the system, and it exists for reasons that have very little to do with what the agent is capable of.

Different settings call for different trade-offs between flexibility and predictability. A few design problems, though, keep showing up in both.

Most of what I’ve written here has been about one of those settings: agents pointed at operational work, where I repeatedly give up flexibility to buy predictable execution. I think I’ve covered that approach fairly thoroughly, and the post about the lightweight DAG engine was the end of that particular thread. What I want to write about next is the other side — the assistant that published this post, and the personal projects around it. Those give me somewhere to experiment and to re-examine assumptions that were correct in the first setting and may not be correct everywhere.

Two settings, two default trade-offs

Operational work tends to arrive with a clear objective and an expensive failure. Someone else depends on the outcome being the outcome, and “done” can usually be stated before the work starts. In that setting I will trade a lot of flexibility for execution I can predict: operators with fixed input and output shapes, success conditions the engine can check without asking a model how things went, exactly two possible results — an explicit error, or the thing I asked for.

Building a personal project is almost the inverse. The goal moves between one session and the next. The method is part of what I’m testing. A rigid pipeline turns every small change into a near-duplicate of the old one, and the family of near-duplicates grows faster than the capability does. Here, being wrong quickly is cheaper than being right slowly, and I want the system to bend rather than refuse.

Underneath both of those is the same observation: a harness is a pile of encoded assumptions about how work should proceed. Every operator signature, every approval gate, every “the agent may not do X” is an assumption somebody decided was worth freezing. The interesting part is not whether you have assumptions — you always do — but how hard you hold each one.

Wording in a prompt suggests an assumption, and the thing being bound by it is also the thing interpreting it. A capability contract or an approval gate states it: written down, auditable, and still obeyed by choice. An engine check holds it, because something other than the model decides whether the condition was met. Moving one assumption downward through those layers is the design move, and it is never free — each step buys predictability and spends flexibility.

I should also say that “work” and “personal projects” are my starting points, not categories. The most tightly gated things I own are in the personal workspace, because that is where publishing and messaging live. And the operational side has plenty of exploratory development where freezing anything early would be a mistake. Development and operations coexist in both; they just have different centers of gravity.

Working assumption: stronger models won’t remove workflow design

This is an assumption, and I’d rather label it than argue it.

I expect context limits to matter for a long time. Not mainly as a window size — as a budget. As a project accumulates history, decisions, dependencies and half-abandoned directions, someone still has to decide what each agent receives, in what order, and what survives between runs. That decision does not become unnecessary when the window gets bigger; it becomes less forced, which is not the same thing.

At the operational end, my answer to that was the DAG engine: reuse pushed down into operators and composition patterns, published as a skill with progressive disclosure — an index first, details for the operators actually in play, examples last. At the personal end the answer looks different, because the workload is different.

The personal workspace is four roles with strict boundaries. A Personal Assistant owns the cross-platform persona, the long-term goals and the routing. A LinkedIn Operator owns exactly one channel and publishes only through a capability Dev provided, on confirmation. A Tech News Tracker gathers and curates and is not allowed to publish anything. Dev — coding subagents — implements capabilities and documents each one’s purpose, invocation, parameters, output, constraints and failure behavior.

What actually carries state between sessions is not the agents. It’s the documents: a role contract per role, a durable operational-knowledge file per role, AGENTS.md files describing the topology and routing rules, and a table of contents for the article pipeline. Beside them sits a ledger — a ClickHouse table, idempotent by kind and key — holding persona, goals, relationships and pending decisions in a form I can query. The Markdown remains the narrative a human can read; the two are reconciled after anything that mattered.

Better models will almost certainly make all of this smoother. They may absorb individual steps entirely, and some of the structure I’ve written will turn out to be scaffolding around a limitation that went away. But I don’t expect task decomposition, information handoff and state management to disappear, because they aren’t model problems. They’re what you get the moment work outlives a single run.

The documents are drifting away from me

That last point has an uncomfortable consequence I’ve started noticing in my own files.

The documents that hand work from one agent to the next get denser over time. Mine are now full of file paths, capability names, routing rules, cross-references, and vocabulary that means something specific inside this workspace and nothing outside it. There are implicit dependencies in them: a line that only makes sense if you already know which role owns which directory. They are precise. They are also optimized for the next agent session rather than for a new human reader, and I would not hand one to a colleague and expect it to land.

I want to be careful not to confuse this with the thing people usually complain about. AI slop is longer and emptier — more words carrying less. This is the opposite: terse, structured, and denser than what I would have written for a person. The problem isn’t quality. The problem is audience.

That’s why I think “prompt engineering” is becoming a bigger job rather than a smaller one, as long as you read the phrase correctly. It isn’t clever phrasing. It’s the design of task instructions, shared documents and handoffs — the interfaces between agents.

This post is an honest example. I wrote the outline, including the claims it had to make. The assistant assembled the context package — persona and goal documents, harness facts, the previous articles — and handed that plus the outline to a coding agent, which produced the prose and the diagrams. Then I read it, cut things, and approved it. The quality of what came back depended far more on that handoff package than on any sentence inside the instruction.

Which leaves a question I don’t have an answer to, and will probably spend a future post on: when agents are the primary readers of a project’s documentation, how do humans get back enough context to understand and direct the project?

Working assumption: the decisions stay mine

The workspace can already update and iterate on itself. After meaningful work it edits its own harness documents, source configuration, watchlist and article index. When a capability is missing, it routes the gap to a Dev subagent, which implements it and publishes an invocation contract back.

That sounds more autonomous than it is, in the way that matters. Every boundary it operates inside is one I set: no publishing without explicit confirmation, browser automation deliberately excluded from news gathering, live deploy out of scope, no capability without a documented contract. The system edits itself freely within a fence it cannot move.

Written out, the split is not subtle. Drafting, gathering and recommending, implementing code, and routine channel operation inside a declared contract are delegated. Positioning and career stance, what counts as done, whether a draft is accurate enough to publish, publishing and deploying, and every autonomy boundary are not.

The article pipeline is the clearest example, because this post went through it. The news pipeline has the same shape: sources are gathered over plain HTTP and git, the whole batch goes to one subagent, and what comes back is a recommendation-only TRACK/SKIP list. It’s advisory. I decide what gets promoted into durable knowledge, and relevance stays anchored to positioning I chose rather than drifting toward whatever was loudest that week.

The same thing is true on the operational side. The initial DAG templates came from human judgment; the engine’s contribution was to enforce boundaries that prompt wording had only suggested. The harness didn’t replace the judgment. It wrote it down somewhere it couldn’t be renegotiated.

So the assumption is this: as more execution gets delegated, the remaining decisions become a larger share of the work rather than a smaller one. I could be wrong about that too — it’s exactly the kind of claim that sounds reassuring, which is a reason to distrust it. What I can say is that the places where my systems have failed have been places where I delegated a decision without noticing it was one.

What comes next

None of this is settled. These are my current judgments, and the only way I know to test them is to keep building and see which ones break.

The next few posts will be about specific personal projects: what they do, how the workflow is put together, and where it went wrong. I’d like each one to sit on a single concrete design decision — what I chose, why I chose it, and what later made me reconsider — rather than another general argument about agents.

The harness is where my judgment gets written down. The part worth writing about isn’t that it runs by itself. It’s which decisions I refused to give it.