Agent Workflow Radar • Operator Foundry

Harnesses Are Becoming the Product

The interesting shift this week is not “more agents.” It is teams hardening the surrounding workflow: repo contracts, model-agnostic shells, layered memory, permissioned delegation, and judge-backed parallel runs.

Short thesis: the winning operator move right now is to treat the agent stack as a governed execution harness, not a chat prompt. The teams shipping fastest are standardizing structure, isolating work, logging eval decisions, and separating memory and permissions into explicit layers.

Six Signals Worth Stealing

These are the most operationally useful patterns from today’s sweep, not the noisiest announcements.

Framework Contract

Agent frameworks are turning into repo-native file contracts

Confidence: Medium

What happened

Vercel introduced eve as an agent framework built around a directory contract: `agent.ts`, `instructions.md`, `tools/`, `skills/`, `sandbox/`, and `schedules/`. Malte Ubl added that the product had already gone through long dogfooding and private beta before launch.

Why it matters

This is a real shift from prompt blobs toward a filesystem-shaped control plane. The repo itself becomes the surface where behavior, tools, runtime boundaries, and scheduling live.

My take

Adopt the directory contract even if you do not adopt the framework. The layout is the steal here: make agent structure legible to humans, version control, and other agents.

Confidence / caveat

Strong directional signal, but still vendor-led. The structure is useful now; the specific framework still needs more field time.

Vercel post Malte Ubl post

Harness Design

The orchestration harness is becoming a first-class layer

Confidence: Medium

What happened

pre.dev framed the “harness” as the orchestration plane around the model: file access, context handling, tool attachment, planning before code, and execution location. The post also argued for cloud sandboxes, model agnosticism, and explicit context-window hygiene.

Why it matters

This reframes agent performance as an infrastructure problem instead of a model-picking problem. If the harness is sloppy, the model quality barely saves you.

My take

This framing is right. The harness is now where reliability lives: isolation, replayability, compaction, permissions, and swap-able models. That is where operator effort should go.

Confidence / caveat

Useful architecture signal, but it is still part manifesto, part pitch. Treat the principles as solid and the product claims as unproven.

pre.dev post

Model Strategy

Model-agnostic agent shells are getting practical, not theoretical

Confidence: Medium-High

What happened

Tibo highlighted that Codex App, CLI, and SDK workflows can be used with open-source models too, not only OpenAI-hosted models.

Why it matters

The workflow layer can now stay stable while the model layer changes for price, policy, latency, or data locality. That cuts vendor lock-in where it hurts most.

My take

Worth adopting now. Keep prompts, tools, evals, and harness rules fixed; swap models by lane. Use frontier models for high-risk reasoning and cheaper or local models for structured grunt work.

Confidence / caveat

The workflow capability looks real, but exact compatibility and behavior still depend on the surrounding toolchain and config discipline.

Tibo post

Memory + MCP

Memory is splitting into layers instead of one giant “agent brain”

Confidence: Medium

What happened

Pieces described a practical split: an on-device workflow memory layer for daily activity, combined through MCP with a separate embedded memory system meant for agent-native recall and relationships.

Why it matters

This is the cleanest memory pattern on the board right now. Personal workflow memory, runtime task memory, and long-lived knowledge should not all be jammed into one store.

My take

Do layered memory. Use MCP as the bridge, not the storage strategy. One layer should remember what you did; another should remember what the task needs; a third can hold curated durable knowledge.

Confidence / caveat

Vendor-posted, but the architecture suggestion is concrete and maps well to real operator pain.

Pieces post

Policy + Delegation

Delegation is getting safer because permissions are finally granular enough

Confidence: High

What happened

The latest Claude Code changelog added parameter-aware tool permission rules such as `Tool(param:value)` and shipped multiple subagent reliability fixes around progress visibility, backgrounding, and disallowed-tool enforcement.

Why it matters

This is what turns subagents from a cool demo into something you can actually trust in a production workflow. Policy can now be scoped by tool input, not just by tool name.

My take

Absolutely worth adopting now if you run background agents. Put hard policy around models, tools, and risky parameter patterns before you add more autonomy.

Confidence / caveat

High confidence because this is a changelog-level product update, not vague positioning. The caveat is operational: fine-grained policy is only useful if you actually maintain it.

Claude Code changelog post

Best Workflow

Spec-driven parallel worktrees are the most stealable workflow in the batch

Confidence: Medium-High

What happened

Aigon described a bluntly useful loop: write a feature spec in Markdown, run multiple coding agents against it in separate git worktrees, have a judge review the results, then merge the winner or cherry-pick the best pieces.

Why it matters

This changes agent selection from vibes into a repo-local experiment. It preserves logs, specs, evals, and final decisions inside the same project history.

My take

This is worth adopting now for medium or large tasks. Do not use it for tiny fixes. Use it when the cost of one bad implementation is higher than the cost of parallel runs.

Confidence / caveat

It comes from a builder, not a broad benchmark, but the workflow is concrete enough to copy tomorrow with tools you already have.

Aigon post

Steal This Workflow

The pattern to steal is not “use more agents.” It is spec-first parallel execution with isolated worktrees, a judge pass, and explicit merge criteria. It borrows the right ideas from Aigon, the harness framing from pre.dev, and the production bar from the eve rollout.

Best for: medium-to-large features, risky refactors, ambiguous implementation choices, or any task where comparing tradeoffs beats trusting one model run.

Skip it for: tiny fixes, pure copy changes, or tasks where test coverage already makes a single run cheap and obvious.

Adopt now? Yes, but start small: one feature spec, two agents, one judge, one merge decision.

1. Write one spec, not three prompts Put success criteria, constraints, test expectations, and out-of-scope notes in a single Markdown spec checked into the repo.

2. Fork the task into isolated worktrees Give each agent its own branch and worktree so file edits, tool calls, and logs stay cleanly separated.

3. Lock policy before the run Define which tools, models, network surfaces, and risky parameter patterns are allowed. Do this once up front, not mid-flight.

4. Require an eval or judge pass Pick a winner based on tests, diff quality, failure handling, and instruction compliance. “Feels better” is not a real rubric.

5. Merge surgically, then store the decision trail Merge the best result or cherry-pick the strongest parts. Keep the spec, logs, eval notes, and final rationale in the repo for replay.

2026-06-17-operator-foundry