Long-Horizon Agents: The Engineering Path from a One-Person Company to a Zero-Person Company

1. From “One-Person Company” to “Zero-Person Company”: What’s Missing Is Engineering, Not Models

A “one-person company” usually describes a team where a single person, supported by AI tooling, handles product, development, operations, and much more. When agents are organized into parallel, division-of-labor “Agent Teams” and start exploring end-to-end autonomous development with no human in the loop, the one-person company evolves into a zero-person company. This does not remove people; it shifts their role from executor to goal definer, rule maker, and result auditor.

What blocks this shift is rarely how smart the model is on a single question. It is four engineering capabilities:

• Long horizon: working continuously for hours or even days without drifting off course;
• High reliability: failures can be classified, retried, and recovered from;
• Supervisability: the whole process is observable, auditable, and interruptible;
• Evolvability: execution traces can be distilled back into model capability.

The sections below break down the engineering pillars of long-horizon agents and the realistic path to self-improving models.

2. Six Engineering Pillars of Long-Horizon Agents

2.1 Externalized planning: from “one step at a time” to “build from the blueprint”

Most agent frameworks use a “think–act–observe” loop: the model decides the next step from the current observation. Once a task stretches into hundreds of steps, stepwise decision-making exposes three problems:

• Goal drift: the long-term objective is gradually drowned out by recent tool output;
• Redundant work: the agent forgets what it has already done and retries the same approach;
• Infinite loops: the agent cycles on the same class of error.

The mature approach is to manage the plan explicitly as a standalone artifact, containing at least four parts:

• Goal and acceptance criteria: what counts as “done”;
• Milestones and exit conditions: each step must produce a verifiable result;
• Artifact list: code changes, test reports, design documents, and so on;
• Resource budget: maximum steps, token usage, wall-clock duration, and cost ceiling.

Each iteration reads only the current milestone, the last few observations, and confirmed conclusions. The long-term goal stays permanently in context, while intermediate steps are folded away. This stabilizes attention and leaves a structured record for recovery and auditing.

{
  "goal": "Add unit tests for the core paths of the order service with coverage of at least 80%",
  "exit_criteria": ["All unit tests pass", "Coverage report meets the target", "No new static analysis warnings"],
  "milestones": [
    {"id": "M1", "desc": "Map module dependencies and locate uncovered branches", "done_when": "Uncovered-code list produced"},
    {"id": "M2", "desc": "Add unit tests module by module", "done_when": "Local test suite passes"},
    {"id": "M3", "desc": "Run coverage and static checks", "done_when": "All metrics meet targets"}
  ],
  "budget": {"max_steps": 150, "max_wall_clock_minutes": 180, "max_cost_units": 2000}
}

2.2 Layered memory: keeping the useful information inside a finite context window

No matter how large the context window is, a long task will eventually fill it. In practice, memory is split into three layers:

• Working memory: code snippets, command output, and intermediate conclusions for the current subtask;
• Task memory: the plan, confirmed facts, and already-failed approaches (to avoid repeating the same mistakes);
• Long-term memory: knowledge recalled from project documentation, historical tickets, and the codebase via vector or keyword retrieval.

The key to context assembly is the trimming policy, which can be driven by a budget priority order:

def build_context(plan, task_state, retriever, budget_tokens=32000):
    """Fill the context by priority: standing goal > current state > retrieved docs > historical summary"""
    context = []
    used = 0
    def add(text, priority):
        nonlocal used
        cost = count_tokens(text)
        if used + cost <= budget_tokens or priority == "always":
            context.insert(0 if priority == "always" else len(context), text)
            used += cost
        return used < budget_tokens
    add(plan.goal + plan.exit_criteria, "always")      # Keep the goal standing to prevent drift
    add(task_state.completed_facts(), "high")          # Compress confirmed conclusions into key points
    add(task_state.failed_attempts(), "high")          # Failed attempts prevent repeated tries
    add(task_state.recent_steps(k=5), "medium")        # Keep only the last few steps verbatim
    for doc in retriever.search(plan.goal, top_k=20):  # Retrieve on demand instead of stuffing everything in
        if not add(doc.snippet, "low"):
            break
    if used >= budget_tokens:                          # Compress overflow history into a summary
        context.append(summarize(task_state.history_before_last_k(k=5)))
    return "\n\n".join(context)

2.3 Tools and the execution environment: the “hands and feet” of long-horizon capability

An agent’s reliability depends heavily on feedback quality. Compilers, test frameworks, and static analysis tools produce objective, binary signals — far more trustworthy than model self-assessment. The execution environment must provide:

• Isolation: run inside containers or sandboxes with restricted filesystem and network access;
• Idempotence and recoverability: write a checkpoint after each completed milestone so an interrupted run can resume from the most recent one;
• Least privilege: inject credentials on demand; never operate on production directly;
• Auditable artifacts: archive code changes, command logs, and test results to object storage.

2.4 Multi-agent orchestration: parallel work with context isolation

The value of multiple agents is not only parallel speedup — it is context isolation: each sub-agent receives only the information relevant to its role. This substantially reduces information interference in long contexts.

Three orchestration patterns are common in the industry:

• Orchestrator–Worker: a lead agent decomposes the task, dispatches work, and aggregates results, while multiple teammate agents execute in parallel. Teammates share a task list and communicate with each other, much like a small development team. This pattern offers strong controllability and suits work with clear goals that can be split cleanly;
• Pipeline: work flows through “plan → implement → test → review”, with each stage objectively validating the previous stage’s output. Best for fixed processes;
• Peer collaboration: several agents discuss and review as equals. Suited to solution exploration, but slow to converge and expensive.

In engineering practice, I recommend centralized orchestration + role isolation + a shared task board: the lead keeps the global view, while workers hold only local context.

def run_agent_team(task):
    board = TaskBoard(task)                       # Shared task board: status, owner, dependencies
    lead = LeadAgent(plan=task.plan, budget=task.budget)
    workers = [WorkerAgent(role=r) for r in ("planner", "coder", "tester", "reviewer")]
    while not board.is_done():
        if lead.should_replan(board):             # Replan when progress is blocked or the direction drifts
            lead.replan(board)
        batch = []
        for w in workers:
            item = board.claim_next(w.role)       # Claim tasks by role; skip if dependencies are unfinished
            if item:
                batch.append((w, item))
        for w, item in batch:                     # Run in parallel with isolated contexts
            result = w.run(item)                  # Sees only code and context relevant to this task
            board.report(item.id, result)         # Write results and evidence back to the board
        board.escalate_if_stuck(threshold_minutes=30)  # Escalate to a human after prolonged no-progress
    return board.collect_artifacts()              # Collect changes, test reports, and decision records

The conventions need to be explicit:

• Task claiming: atomic claims, so two agents never modify the same file;
• File ownership: ownership assigned per directory; reviewers are read-only;
• Escalation: after N consecutive failures on the same error, or when the budget is exhausted, escalate to a human.

2.5 The verification loop: driving self-correction with objective signals

Whether a long-horizon agent can truly “self-correct” depends on whether it can tell a real failure from a false success. The recommended practice is to fix verification into a repeatable chain of checks:

CHECKS = [("compile", run_compile), ("unit", run_tests),
          ("lint", run_lint), ("security", run_sast)]
def verify(change):
    failed = [name for name, check in CHECKS if not check(change).passed]
    if not failed:
        return "PASS"
    if len(failed) == 1 and failed[0] in ("unit", "lint"):
        return "RETRY"          # Single fixable issue: retry with the error message
    return "ESCALATE"           # Multiple failures or security issues: escalate to a human

A retry is not simply “try again.” Each retry should carry the failure evidence, the approaches already attempted, and explicit “do not repeat” constraints, plus a maximum retry count — otherwise the agent digs deeper in the wrong direction.

2.6 Observability and governance: unattended does not mean unaccountable

When agents run autonomously for hours, being unable to see what is happening is more dangerous than doing the job poorly. The minimum observability set includes:

• End-to-end tracing: one unique trace per task, recording the input, output, tool calls, and duration of every step;
• Key metrics: task success rate, human-intervention rate, per-task cost, and average step count, wired into monitoring and alerting;
• Operation audit: immutable audit logs for high-risk operations such as code commits and deployments;
• Tiered approval: read operations may run automatically, write operations require confirmation by default, and irreversible operations (deleting data, changing production configuration) must be approved by a human.

3. Self-Improving LLMs: Not Editing Weights at Runtime, but an Automated Learning Loop

“Self-improving LLMs are the most promising direction” is a common judgment in the industry, and it needs clarification: today’s self-improvement is not the model modifying its own weights during inference. Instead, agent execution traces are distilled into high-quality training data, and capability iteration happens through standard training pipelines. The chain breaks down into four steps:

1. Collect: record complete agent trajectories, including the task description, intermediate steps, tool calls, and final result;
2. Filter: prioritize trajectories that pass objective checks (compilation, tests, review), plus high-value cases confirmed by humans;
3. Transform: turn the filtered trajectories into training samples — for example, “task + correct solution” for supervised fine-tuning, or “good answer vs. bad answer” pairs for preference optimization;
4. Iterate: train a new model version, run a regression comparison on a fixed evaluation set, and roll out gradually only after it passes.

Key technical directions

• Reinforcement learning with verifiable rewards (RLVR): use automatically judgeable signals such as test pass rate, compilation success, and lint compliance as rewards, reducing manual labeling;
• Rejection-sampling self-training: generate multiple solutions per task and keep only the ones that pass verification for training, which mitigates exposure bias;
• Preference optimization: build preference pairs from “reviewer agent + human spot checks” to optimize subjective qualities such as code style and readability;
• Process-level feedback: reward not only the final result but also key steps (approach selection, root-cause localization), addressing the sparse-reward problem in long tasks.

Main risks

• Reward hacking: agents may learn to “please the metric” instead of solving the problem — deleting failing tests so the suite “passes,” or covering only easy code to inflate coverage. Countermeasures: multiple independent checks, held-out evaluation sets, and human spot checks;
• Data contamination: if training data contains evaluation-set samples, offline metrics look inflated while online performance drops;
• Catastrophic forgetting: training on new tasks can degrade existing capabilities. A fixed regression set and periodic comparison against the previous version are required;
• Feedback bias: training only on successful trajectories erodes the model’s ability to handle failure scenarios, which is why failure-analysis data matters just as much.

4. Adoption Path: A Four-Stage Progression

Stage	Human–agent division of labor	Key investments	Core metric
L1 Assistive	Humans lead; the agent offers suggestions and code completion	Tool integration, prompt conventions	Acceptance rate
L2 Semi-autonomous	Agents execute autonomously; humans confirm at critical checkpoints	Externalized planning, checkpoints, approval flow	Human intervention rate
L3 Long-horizon autonomous	Humans engage at the goal and rules layer; agents run autonomously for long periods	Multi-agent orchestration, sandboxing, end-to-end tracing	End-to-end task success rate, cost per task
L4 Self-evolving	Humans define goals and evaluation criteria; the system automatically harvests data and iterates the model	Data flywheel, regression evaluation, gradual rollout	Capability growth rate, regression defect count

Most teams have no need to jump straight to L3. The safer sequence is:

1. Accumulate enough task trajectories and failure samples at L2;
2. Use that data to train verifiers and reviewer agents;
3. Gradually widen the permitted duration of autonomous runs and the scope of permissions.

5. Cloud Foundations: Turning an “Agent Team” into Operable Infrastructure

For a “zero-person company” to run stably, the cloud infrastructure needs to cover four capability areas. On Baidu AI Cloud, they map as follows:

• Elastic execution substrate: use the container platform’s elastic scaling and isolation to provide independent sandbox workspaces for large numbers of parallel agents; use object storage to archive code artifacts, test reports, and training data; use a message queue to carry asynchronous tasks and inter-agent event notifications;
• Observability system: collect and alert on agent execution traces through log services and monitoring/alerting, so infinite loops, cost anomalies, and falling success rates are caught early;
• Memory and knowledge layer: combine vector retrieval with unified data management to build a team knowledge base that is shareable and updatable;
• Model iteration loop: use the model training and inference platform to run the “filter → train → evaluate → gradual rollout” cycle, and expose stable inference capability through model serving.

6. Checklist: Can the Agent Run Unattended?

Before letting an agent run unattended for long periods, confirm each item:

1. Does the task have clear exit criteria that can be judged automatically?
2. Are the plan, state, and artifacts persisted so the run can resume after an interruption?
3. Are there objective verification signals (compilation, tests, static analysis)?
4. Is there clear task ownership and conflict control across agents?
5. Does every irreversible operation have an approval step and a rollback plan?
6. Is there a hard cap on budget (steps, duration, cost)?
7. Are failures classifiable and retryable, and is there an escalation path to a human?
8. Is every execution traceable and auditable?
9. Are high-quality trajectories systematically harvested for model iteration?
10. Is there a fixed regression evaluation and gradual rollout mechanism before a new model ships?

Conclusion

The point of a “zero-person company” is not to eliminate people, but to move their work up a level — from stepwise execution to defining goals, designing rules, and evaluating results. Long-horizon agents determine how far the system can go, the self-improvement loop determines whether it gets better over time, and observability and governance determine whether that autonomy is safe and controlled. Solidify L1 and L2 first, then advance gradually to L3 and L4 — that is the most reliable path to a zero-person company.