Long Horizon Agents
Krish Chelikavada
Most agents today wait for a task.
You ask them to review a pull request, research a market, or implement a feature. They finish the work, return a result, and stop.
Long horizon agents keep ownership of a goal over days, weeks, or months.
They share context, watch for new signals, and decide which tasks to execute next. Every result updates their understanding of the goal and changes what they do after.
Two examples
Give an agent the goal: increase activation without increasing support load.
It reads product events, support conversations, and past experiments. It decides to interview churned users. The interviews point to a slow setup flow, so it runs an onboarding experiment. Support tickets go up, so it changes the experiment and watches again.
Or give an agent the goal: keep gross margin above 80% while latency stays below 300ms.
It sees an inference cost spike and traces it to one customer workflow. It runs a cache experiment, watches latency after rollout, and decides whether to expand or revert the change.
The output is better margin and stable latency. The work required to get there can change every week.
Task agents
Codex and Claude Code are task agents.
You can say: “Implement usage based billing.”
The agent explores the codebase, makes a plan, opens subagents, writes code, runs tests, repairs failures, and returns a result.
The request defines the work and the end of the run.
A user asks a coding agent to add usage based billing. The agent delegates research, implementation, and tests to subagents, completes the task, and stops.
Agents can also run in loops.
A pull request triggers a review agent. Monday morning triggers a reporting agent. An error threshold triggers a triage agent.
These loops are useful. The trigger and task are configured in advance.
A pull request signal follows a configured route into a review agent. The agent posts the review, stops, and waits for the next pull request signal.
Three axes that actually differ
| Axis | Task agent | Trigger loop | Long horizon agents |
|---|---|---|---|
| Who decides the next action | Person | Configured trigger | Agent |
| Context | One run | Limited per run | Accumulates across the goal |
| Termination condition | Task complete | Event handled | Goal achieved or stopped by a guardrail |
Long horizon agents
Long horizon agents start with context built for a specific goal.
The context engine is the glue that ties the system together. It can include SOPs, context graphs, wikis, previous decisions, past work, and live signals.
It carries history and memory across tasks, so the orchestrator and every task it creates know what has already been done and can use that context when relevant.
A context engine guides an orchestrator. Signals become tasks in a work queue, and completed tasks return as new signals.
- Context engine: carries shared knowledge, history, and memory across tasks.
- Signal: reports an external change or the result of a completed task.
- Orchestrator: reads the context and decides what should happen next.
- Task queue: holds the work chosen by the orchestrator.
When a task finishes, its result becomes a new signal. The orchestrator reads it, updates the plan, and decides what enters the queue next.
A good result becomes memory. A bad result changes the plan. An external signal can move ahead of the existing queue.
The agent gets a bounded objective, explicit permissions, budgets, approval thresholds, and an audit trail. It owns the next decision inside those guardrails.
Jina as the maintenance layer
Our fundamental belief behind Jina is that the bottleneck in software engineering has shifted from coding to resilience.
Coding agents can ship more changes than teams can review, test, and monitor.
Jina starts with a wiki built for QA and maintenance. It captures architectural diagrams, dependencies, operating procedures, issue history, and what correct behavior looks like.
A context graph connects that knowledge to the code, infrastructure, and runtime behavior. Jina uses it to review each pull request, plan the blast radius, and run the relevant parts of the app.
A pull request is one signal in a longer maintenance system.
Say an OAuth pull request opens. That signal calls Jina’s orchestrator, which adds a targeted review to the work queue.
The review finds that a PKCE check can be bypassed. That issue returns to the orchestrator as a new signal.
The orchestrator adds a deeper auth review and a production monitor.
Days later, the monitor sees callback failures rise. It calls the orchestrator, which adds a review of the related code, ships a fix, and adds a new monitor for refresh token rotation.
A pull request calls Jina's orchestrator. It creates a review, uses the findings to add a deeper review and production monitors, then uses runtime issues to review related code, ship a fix, and add new monitors.
Jina decided each task from the result of the task before it.
That is our vision for autonomous maintenance.
Jina keeps watching, deciding, and fixing until the system is healthy.
Citation
Please cite this work as:
Chelikavada, Krish, "Long Horizon Agents", Om Labs, Aug 2026.
Or use the BibTeX citation:
@article{chelikavada2026longhorizonagents,
author = {Krish Chelikavada},
title = {Long Horizon Agents},
journal = {Om Labs},
year = {2026},
note = {https://omlabs.xyz/blog/agents-that-decide-what-to-do-next},
}