When the Caller Is an Agent

Cover Image for When the Caller Is an Agent

Listen with Article TTS Reader

Checking for Article TTS Reader…

≈ 13 min read

Two pieces of reading landed next to each other in my notes: Anthropic's account of redesigning source control and 言之's survey of Personal AI, which frames the product around a continuing relationship with a person—remembering context, noticing events, and acting within delegated authority.

They describe opposite ends of the same problem: ongoing delegation turns a person's occasional requests into repeated reads, experiments, and writes. Personal AI expands when work happens; Scion shows the infrastructure pressure an agent-heavy workload can create.

In The Age of Intention, I wrote about directing several bounded workstreams while keeping responsibility for their outcomes. That experience has made me reconsider who is operating our software. The person expressing the goal and reviewing the result may increasingly differ from the caller making the requests.

Agent-native software has to reconsider both its interaction contract and its workload assumptions. A tool wrapper and more servers can help, but neither establishes reliable delegation by itself.

The workload changes

Anthropic reports growth from around 2,500 merged changes daily in May 2026 to over 30,000 in September, alongside roughly 25 million CI checkouts per day. Its architectural question is concrete: if a job needs a diff or one subtree, why should it maintain a local repository capable of answering much more?

Scion moves history queries, merges, and other operations onto a service. Clients fetch immutable objects through tiered caches. Some operations need no working copy; sparse and virtualized checkouts reduce what other jobs materialize. Changing what consumers need to fetch changes the workload's economics.

These are vendor-reported figures from an unusual environment. Git already supports partial clones and sparse checkouts, and systems such as Sapling provide substantial prior art. Anthropic explicitly says Scion is unsuitable as a general Git replacement. Its dependence on reachable services also trades away offline independence.

The transferable lesson is to inspect assumptions. An excellent design can become expensive under a different mix of callers, concurrency, and data access.

One interaction becomes two

Personal AI extends delegation beyond individual prompts. Watching a project or preparing a recurring report can generate work whenever a document changes or a deadline approaches. I find it useful to distinguish two interfaces:

  • Human–agent interaction (HAI): goals, assumptions, delegated authority, review, correction, and interruption.
  • Agent–computer interaction (ACI): capability discovery, relevant state, execution, feedback, and recovery.
A person delegates through an agent harness or acts directly. Both execution paths reach application state through authorization enforcement, with results available for review.

This is a conceptual boundary; enforcement may live in applications, gateways, or the operating system. A model's intention grants no permission. The two interfaces must agree on the task, authority, and evidence, or a misunderstanding can be executed very efficiently.

The GUI is a human abstraction

Windows, menus, and pointing devices organize computation around someone who can look, recognize, point, and observe a change. Menus reduce the need to remember syntax; windows keep working context visible. Those are responses to human capabilities, rather than requirements intrinsic to editing a document.

An agent operating that surface may have to recover a semantic operation from its visual representation: find the window, locate an object, open a menu, and inspect the result. The application already knows its objects and commands before rendering them.

This tension predates modern models. In their 1997 debate, Ben Shneiderman and Pattie Maes contrasted direct manipulation's predictability and control with agents' potential to handle complex delegated work. Eric Horvitz's 1999 mixed-initiative principles brought the approaches together: consider uncertain goals, interruption costs, ways to terminate automation, and opportunities to refine results.

Modern research adds a useful correction: terminal text is not automatically agent-friendly either. SWE-agent holds the model fixed while changing commands and feedback. Its experiments show how one-result-at-a-time navigation wastes steps, silent success triggers extra verification, and excessive output consumes context. AXIS studies API-first execution with UI fallback in Word tasks. Both support interface-sensitive design, rather than universal API superiority.

My conclusion is that agents need selective state queries, identifiable objects, discoverable commands, and explicit outcomes. Humans still need visual surfaces for judgment and intervention. Karpathy makes a related distinction in the “Building for agents” section of his 2025 YC AI Startup School talk, alongside advocating interfaces that accelerate human verification. A successful image-editing command cannot tell me whether the composition looks right.

Computers bridge existing software

Cloud computers give agents access to applications without complete APIs. Manus describes a virtual-machine sandbox and filesystem context; Dots presents always-on agents with cloud computers; Orgo exposes computers through programmable interfaces.

The layers remain distinct. A model selects actions, a harness manages execution, and a computer supplies processes and files. At the infrastructure layer, lightweight VMs such as Firecracker provide isolation. Task permissions and recovery semantics still need to be designed above that boundary.

I want a durable task journal recording authority, completed operations, unresolved effects, and artifacts, even if the computer is replaced. Restoring a machine snapshot cannot unsend an email or reverse a payment already accepted elsewhere. Persistence of the desktop and persistence of the responsibility are different problems.

Applications can share an engine

The ArtCraft projects illustrate another path. PhotoCraft describes a document model and command engine shared by its GUI, CLI, JSON channel, and MCP server. DeckCraft similarly documents stable commands and headless or running-app control.

A presentation engine can expose slides, layouts, and shapes directly. A person can then inspect the same document and make visual corrections. Rust and WebAssembly support these projects' portability strategy; their agent-facing value comes from the command contract, not the language alone.

PhotoCraft is still early alpha and explicitly warns against treating it as a daily Photoshop replacement. The shared-engine architecture is useful to examine even while compatibility and professional reliability remain work in progress.

Mature software has offered scripting for decades. The useful pattern is a shared engine with human-facing and agent-facing interfaces, rather than duplicated business logic or mandatory click simulation.

Throughput and context are different budgets

A fast endpoint can still be awkward if it returns thousands of records for a model to sift through. Anthropic's code-execution pattern and Cloudflare Code Mode move intermediate tool composition and filtering into code, returning bounded results to the model. Execution still needs isolation and access controls.

There is a parallel with Scion: avoid moving data to consumers that do not need it. Relevant filters, bounded pages, and artifact references help, provided responses expose freshness, versions, and whether results are complete. A sample mistaken for the whole dataset is dangerous.

Delegation can also amplify activity. One report fans out across several services; polling repeats reads; timeouts trigger retries; concurrent workers act on stale state. Measure that amplification before choosing incremental reads, batching, or concurrency limits. Agents do not automatically require a new storage architecture.

A meeting move reveals the hard parts

Consider: “Move next week's project review, update the agenda, and tell the participants.” One request spans calendars, documents, and messages. A useful interface should support a sequence like discover → read → propose → authorize → execute → recover, with explicit side effects and per-operation status.

If someone edits the calendar after approval, a conditional write should reject the stale version. Refreshing the plan may require renewed approval: permission for Tuesday at 10 should not silently become permission for Thursday at 7.

If a notification succeeds but its response times out, repeating the task could duplicate messages. A persisted operation record and a correctly scoped idempotency key let retries recover results within the service's defined retention and payload rules.

If the calendar changes but the agenda write fails, the task is partially complete. Recovery may mean finishing the agenda or asking for help. Automatically reverting the event could conflict with intervening work. The person needs an honest account of completed effects and remaining decisions.

Schemas validate request shape. They cannot establish that a recipient is appropriate, a result is correct, or an action is authorized. Those require domain rules, enforcement, and review.

Keep the human in control

For ongoing work, I want to see the agent's understanding of its task, active authority, proposed changes, and execution receipts. A long chat transcript is a poor substitute for that state. Explanations should remain distinguishable from evidence that an operation succeeded.

Approving every harmless read makes me the scheduler. Unrestricted future access creates the opposite problem. Bound authority by resources, actions, cost, and duration, then escalate when needed. Stripe's scoped payment tokens illustrate enforceable usage and expiration limits. Remembered preferences can inform a proposal; they should not grant permissions.

Oversight itself needs testing. The “Dark Patterns Meet GUI Agents” preprint finds different human and agent failure modes, with supervision improving avoidance while adding cognitive costs. “Stop” must also specify which new effects it prevents and which operations are already in flight.

What happens when the caller changes itself?

Recursive self-improvement (RSI) adds another interaction problem: the agent we delegate to may propose changes to its own future behavior. My research notes distinguish fixing today's output, retaining a useful skill, and improving the mechanism that proposes and selects future improvements. These are different claims; RSI has no single agreed threshold. More versions or a larger memory do not, by themselves, demonstrate increased capability.

One possibility is to run isolated agent variants and have a group of reviewer agents cross-check their work. The attraction is clear: automate routine checking and bring people the consequential disagreements. But asking a person to compare every candidate creates a full-time judging job. Multiple agents can also share blind spots or become better at satisfying a rubric without producing more useful work. Reliable selection pressure for open-ended tasks remains an open question.

My bounded RSI experiment separates execution from evidence and candidate promotion. That is a starting point, not proof of sustained recursive gains. From an HCI perspective, I still see several gaps:

  • Separate task acceptance from behavior promotion. “This fix works” should not mean “make its workaround a permanent rule.” A user needs to understand which decision they are making, the scope of a retained lesson, and when it should expire.
  • Make behavioral change reviewable. A code diff may not reveal that the next agent will ask fewer questions, spend more, or perform worse on another task family. Review needs examples, regressions, uncertainty, and cost alongside the proposed benefit.
  • Preserve continuity and identity. A process restarting, a task resuming, a deliverable completing, and a new version passing evaluation are distinct events. Reports should identify the active generation and what evidence carries across the transition.
  • Reduce supervision without hiding decisions. Which comparisons can be automated, which require judgment, and when should disagreement interrupt someone? Fewer notifications alone cannot measure success if understanding or control deteriorates.

The workbench I would investigate separates work, learn, and govern: complete tasks, test candidate improvements, and authorize durable changes. Evaluation safeguards, permissions, budgets, and recovery controls should remain outside the candidate's editing authority. Development checks also need separation from protected qualification; repeatedly selecting against a holdout consumes its independence.

To investigate that design, I would test whether people can understand a behavior change, reject it, and restore a known generation without reconstructing an experiment history. Restoration would still not undo external effects. The question is whether improvement can become less labor-intensive while preserving meaningful human direction—not merely whether an agent can rebuild itself.

Missing pieces—and where standards could help

I would build on existing protocols before inventing another universal agent standard. Several already address parts of the problem, although their maturity, versions, and implementation coverage differ:

Existing effort Useful contribution What that alone does not establish
MCP Tool, resource, and prompt interfaces, plus an HTTP authorization framework Domain-specific permission enforcement or qualification of changed behavior
Agent Client Protocol Client–agent sessions, progress, permission requests, and cancellation Portable hidden session state or reversal of completed effects
AG-UI Frontend events, shared-state updates, and interrupt/resume structures A canonical experiment record or proof that someone understood an approval
A2A Agent discovery, task lifecycles, messages, and artifacts Independent evidence that an advertised capability is trustworthy
OpenTelemetry's GenAI conventions Common telemetry vocabulary for connecting operations and investigating behavior A judgment that an outcome was correct or a candidate improved

These are complementary specifications and evolving conventions, not interchangeable or uniformly adopted standards. A protocol can carry a permission decision; the runtime and target service still have to enforce it.

The missing layer I would investigate is a small set of shared contracts for delegated work and behavior change. A portable task record could carry goals, constraints, artifact references, completed effects, unresolved decisions, and required controls. Another runtime could use it to continue work without pretending to inherit the previous model's internal state.

A behavior-change record could identify the baseline and candidate generations, the scope of the change, evaluation conditions, regressions, approval, and restoration path. Runtime identity would need to include the model, loaded extensions, configuration, and relevant memory snapshot—not merely a product name. Sensitive content should remain access-controlled; interoperability is not a reason to export every conversation.

Industry collaboration could contribute schemas, adapters, and conformance tests: does cancellation actually stop new work, does a stale approval fail closed, and can a reported generation be restored? Shared test fixtures could make those claims comparable across implementations. They would still need human studies of comprehension, correction effort, and review fatigue.

I would standardize evidence and decision boundaries before trying to standardize “intelligence.” Comparable records would help us investigate whether delegation and adaptation work, without requiring every system to share one optimizer, interface, or definition of RSI.

Where I would start

I would start with one troublesome workflow and measure outcomes, wrong actions, recovery effort, context volume, requests, and interruptions. Improve an adapter before considering a rewrite. Test ambiguity, stale state, permission changes, timeout-after-success, and partial failure with actual agents as well as contract tests.

I want to delegate a responsibility and return to inspect a result without reconstructing every click or trusting a confident paragraph. That requires treating the agent as a first-class caller while preserving the human's authority and ability to intervene.