Digital Apprentice: Earned Autonomy for AI Agents

The useful question in agent design is no longer "can this system act autonomously?" It is "which exact skill has earned which exact level of autonomy, under which evidence, with which rollback path?"

That is the engineering lens behind arXiv:2606.04321, "The Digital Apprentice: A Framework for Human-Directed Agentic AI Development", submitted on June 3, 2026 by Travis Weber and Rohit Taneja. The paper argues for a developmental model of agency: an AI agent should internalize a directing human's methodology, earn autonomy per skill, and keep correcting drift as new feedback arrives.

Effloow Lab ran a small local sandbox PoC for this article. The PoC did not use an LLM, did not call an API, and did not reproduce the paper's corpus experiment. It simulated the control-plane mechanics that matter to builders: per-skill autonomy tiers, approval evidence, high-risk pauses, and demotion when a skill drifts. The evidence note is saved at data/lab-runs/digital-apprentice-human-directed-autonomy-2606.md.

The short result: earned autonomy behaves differently from a global "agent is trusted" switch. In the simulation, a low-risk triage skill earned limited execution autonomy after repeated approvals, while refund and deploy skills stayed human-reviewed because they were high risk. When triage quality later dropped, the system demoted that skill instead of letting past approvals carry it forward.

Why This Matters

Most production agent conversations still collapse autonomy into a single product property. An agent is described as autonomous, semi-autonomous, human-in-the-loop, or assistant-like. That vocabulary is too coarse for real systems.

A coding agent may be safe to format files automatically, but not safe to push to production. A support agent may be safe to classify tickets, but not safe to issue refunds. A research agent may be safe to collect sources, but not safe to publish a compliance memo. These are different skills, risks, tools, and failure modes.

The Digital Apprentice paper frames this as a governance problem, not just a model capability problem. Heavy oversight limits scale. Broad autonomy outruns accountability. The proposed middle path is earned autonomy: capture the human's methodology, authorize escalation explicitly, and keep alignment alive through runtime correction.

That direction lines up with practical agent-building advice from several independent sources. The OpenAI Agents SDK human-in-the-loop docs describe approval flows for local tools, MCP tools, hosted MCP tools, and durable RunState serialization. Anthropic's Building Effective Agents guidance distinguishes workflows from agents and emphasizes environmental feedback, checkpoints, stopping conditions, and human judgment when blockers appear. NIST's AI Risk Management Framework focuses on governing, mapping, measuring, and managing AI risk rather than treating trust as a static claim. OWASP's Agentic AI Threats and Mitigations resource treats autonomous tools as an expanded attack surface that needs threat modeling and mitigations.

Two research references are also useful context. "Levels of Autonomy for AI Agents" separates autonomy level from capability and operating environment, which reinforces the idea that autonomy is a design choice. "SoK: The Attack Surface of Agentic AI -- Tools, and Autonomy" maps agentic risks across prompt injections, knowledge-base poisoning, tool exploits, and multi-agent threats.

The overlap is clear: autonomy is not a vibe. It is a controlled permission system connected to evidence.

The Digital Apprentice Model

The paper's abstract names three architectural components:

1. Methodology capture: distill a directing professional's tacit workflow into structured assets.
2. Authorization: escalate autonomy only through explicit human approval.
3. Continuous alignment: correct drift at runtime and convert corrections into owned preference data.

For developers, the strongest part of that framing is the phrase "per-skill autonomy tiers." It avoids a common deployment mistake: trusting the whole agent because one part of it performed well.

Suppose an internal operations agent handles three skills:

• triaging inbound tickets
• drafting refund decisions
• preparing deployment checklists

Those skills should not share a trust meter. Triage may have a long history of accepted outputs and low downside. Refunds involve money and policy exceptions. Deployments involve uptime and customer impact. A system that promotes the entire agent after enough successful triage runs has learned the wrong lesson.

The Digital Apprentice view suggests a control plane around the agent. The model can still reason, draft, call tools, and ask for help. But the control plane decides what the agent may do without review, what needs approval, what must stay observe-only, and when previous autonomy should be revoked.

What Effloow Lab Simulated

The sandbox used Python 3.12.8 and the standard library only. It modeled three skills: triage, refund, and deploy. Each skill had an independent tier:

tier 0: observe_only
tier 1: draft_requires_review
tier 2: execute_low_risk_with_review_log
tier 3: execute_with_spot_checks

The promotion rule was intentionally strict:

if rolling_quality >= 0.90 and approvals >= 3:
    skill.tier = min(3, skill.tier + 1)

The demotion rule was intentionally conservative:

if corrected or risk == "high":
    skill.tier = max(0, skill.tier - 1)
    decision = "pause_for_human"

This is not a benchmark. The quality scores were synthetic. The human approvals were simulated. The point was to test whether the control-plane shape preserves the difference between "this skill has evidence" and "the agent is generally trusted."

Here is the critical run behavior:

03 triage  q=0.93 risk=low  tier 0->1 decision=promote_or_execute
04 triage  q=0.92 risk=low  tier 1->2 decision=promote_or_execute
05 refund  q=0.90 risk=high tier 0->0 decision=pause_for_human
07 deploy  q=0.87 risk=high tier 0->0 decision=pause_for_human
08 triage  q=0.79 risk=low  tier 2->1 decision=pause_for_human

The useful result is not that a toy script produced a fancy score. It is that the policy made the right separations:

• repeated low-risk triage approvals promoted only triage
• high-risk refund and deploy actions stayed human-reviewed
• one degraded triage event demoted triage despite earlier success
• recovery required more than one good follow-up event

That last point matters. A system that instantly re-promotes after one clean response is not really managing trust. It is just oscillating.

Practical Architecture

A production version of this pattern needs more than a prompt. It needs state, policy, evidence, and interfaces for human review.

At minimum, the control plane needs a SkillState record. That record should not live only in the model context. It should be application state that survives sessions:

{
  "skill": "refund_decision",
  "tier": "draft_requires_review",
  "rolling_quality": 0.86,
  "approval_count": 18,
  "correction_count": 4,
  "last_demoted_at": "2026-06-06T00:00:00Z",
  "allowed_actions": ["draft_refund_response"],
  "blocked_actions": ["issue_refund", "change_billing_status"]
}

The agent runtime then asks the control plane before acting:

1. What skill is this action part of?
2. What is the current tier for that skill?
3. Is the requested tool low-risk, reversible, or high-risk?
4. Does this action need human approval?
5. How will the result be evaluated?
6. What evidence updates the skill state afterward?

That pattern fits naturally with the current tooling ecosystem. OpenAI's Agents SDK approval APIs can interrupt tool calls and resume durable run state after a decision. Anthropic's guidance on agent checkpoints and environmental ground truth fits the same loop: do not rely only on model confidence; inspect what happened. OWASP's agentic threat model pushes teams to think about tool access, external knowledge, and autonomous loops as security boundaries. NIST's AI RMF gives the broader governance vocabulary for documenting risks and controls.

The missing layer in many teams is the promotion ledger. They have tool approvals, but not a durable answer to "why is this agent allowed to do this now?" Earned autonomy requires that answer.

Common Mistakes

The first mistake is promoting by task volume. A thousand successful low-risk classifications do not justify autonomous refunds, deployments, deletions, or purchases. Promotion evidence must match the skill and the action class.

The second mistake is treating human approval as a permanent trust grant. Approval should be evidence, not a blank check. If the environment shifts, the policy changes, or the user corrects the agent, the skill should lose autonomy until it earns it again.

The third mistake is hiding methodology in prompts. Prompts are useful, but methodology capture needs explicit artifacts: examples, checklists, rubrics, policy snippets, rejected cases, accepted cases, and the reason behind corrections. Otherwise, every new model, prompt edit, or tool update can silently change behavior.

The fourth mistake is ignoring reversible versus irreversible action design. A tier that allows "draft a reply" is not the same as a tier that allows "send the reply." A tier that allows "prepare a migration plan" is not the same as one that allows "run the migration." The action boundary should be part of the skill definition.

The fifth mistake is making review too frequent and too shallow. Approval fatigue is real in agent workflows. Effloow previously covered this in LLM Agent Security Is a Human Problem. Earned autonomy should reduce low-value review while preserving deliberate review for actions that deserve attention.

Implementation Checklist

Start with a skill inventory. List what the agent does in operational language, not generic model language. "Summarize customer context" is a skill. "Search docs" is a skill. "Approve refund" is a separate skill. "Deploy release" is another separate skill.

Then assign initial tiers. New skills should start at observe-only or draft-only. Existing deterministic workflow steps may start higher if there is real evidence, but record the evidence rather than relying on memory.

Next, define promotion criteria. Use thresholds that reflect risk:

• minimum number of reviewed cases
• rolling quality score or rubric pass rate
• maximum correction rate
• required review by role
• cooldown period after demotion
• explicit blocked tools by tier

After that, wire runtime approvals. If a tool call crosses the tier boundary, interrupt and ask for approval. If a tool call is high-risk, require approval regardless of recent quality. If a correction appears, demote or freeze the skill.

Finally, keep an audit trail. A useful log entry should answer:

• what the agent wanted to do
• which skill and tier applied
• whether the action was approved, rejected, or edited
• what result came back from the environment
• whether the skill state changed

This is also where sandboxing fits. For infrastructure-heavy agents, read Anthropic Self-Hosted Sandboxes: Worker Pattern PoC. For guardrail tests, see OpenAI Agents SDK Guardrails: Local Sandbox PoC. Earned autonomy is strongest when tool execution, approval policy, and sandbox boundaries reinforce each other.

FAQ

Q: Is Digital Apprentice an agent framework I can install?

No public installable framework was verified during this run. The source used here is the arXiv paper, which presents a framework and control-plane idea. Treat it as an architecture pattern unless a maintained implementation is separately verified.

Q: How is earned autonomy different from human-in-the-loop approval?

Human-in-the-loop approval is a mechanism. Earned autonomy is a policy around when that mechanism is required, reduced, or restored. A system can have approval dialogs and still fail at earned autonomy if approvals are not tracked per skill or if corrections do not change future permissions.

Q: Should every agent use autonomy tiers?

No. A narrow workflow with fixed steps and no meaningful irreversible action may only need ordinary validation and logging. Autonomy tiers become valuable when one agent handles multiple skills with different risk levels, especially when some actions can affect money, production systems, user data, compliance, or external communication.

Q: Can an LLM decide its own tier?

It can help classify the requested action, but it should not be the sole authority for its own permission level. The tier should be application state controlled by policy, evidence, and human review. Otherwise, the agent is effectively grading its own escalation.

Key Takeaways

The Digital Apprentice paper is useful because it shifts the autonomy conversation away from blanket trust and toward earned, scoped delegation. That is the right direction for production agents.

The sandbox PoC was intentionally small, but it exposed a practical design rule: trust must attach to a skill, not to the agent as a whole. Low-risk triage evidence should not promote refund or deployment autonomy. A correction should demote the affected skill. Recovery should require fresh evidence, not optimism.

For teams building real agents, the practical next step is not to ask for "more autonomy." It is to define the smallest skill that can safely earn autonomy, the evidence required to earn it, and the event that revokes it.