AI agent planning and execution loop: holding a plan, choosing the next task and resuming

How should an AI agent hold a plan, choose the next piece of work when several goals and approaches compete, execute it, and pick up again after a session break? AR Labs researched that question in November 2026, taking as the case the marketing manager agent in our multi-agent system. The report draws on marketing planning practice (SOSTAC, OKRs, agile marketing), published agent harness designs (a harness is everything around the model that shapes what an agent does: the agent program, its instructions, skills, hooks, tools and checks), and the source of four open-source marketing-agent packages, and keeps what the sources say apart from our interpretation.

In the agent this research supported, written records held goals, approaches and tasks, and a current-work section in a state file was the resume point, but nothing ordered the tasks or said which was next. Three terms recur. A frame is one item at one logical level (a marketing goal, an approach) with everything inside it. A task is work that completes, attached to the frame it serves, with subtasks. The weekly review is the standing routine in which the agent checks in on key results.

Method: web research on marketing planning practice and agent harness design, with the most load-bearing primary sources fetched and read (Anthropic's long-running harness post, the Agile Marketing Manifesto). The four marketing-agent repositories were shallow-cloned and the relevant files read: iamwaqargulzar/Marketing-Agent-OS, aaron-he-zhu/aaron-marketing-skills, coreyhaines31/marketingskills and anthropics/knowledge-work-plugins (marketing plugin). Hermes facts come from an earlier review of the Hermes code, not from new inspection; Hermes-specific builds are covered in a companion report. Each section keeps evidence (what sources say) apart from interpretation (marked "Interpretation").

Finding

Every source that survives contact with real work, human or agent, uses the same three-part loop: a durable list of discrete work items with a status each, a rule for picking exactly one next item, and a write-back after each item that a fresh reader can trust. Marketing practice adds a second, slower loop on top: a weekly check-in that re-ranks the work against goal confidence, and a quarterly cycle that resets the goals. The agent studied here had the slow loop and a resume pointer; it lacked the fast loop's middle part, an explicit order between tasks and an explicit selection rule.

The agent literature is consistent about what makes a plan survive a session break. Anthropic's long-running harness keeps the plan as a structured file of items with a pass/fail flag, a separate free-text progress log, and git history; each session reads all three, picks the highest-priority unfinished item, works on one item only, verifies it, and writes back (Anthropic). Plans that did not survive, from BabyAGI-style queues to one-shot attempts, held the plan in the conversation, let the model regenerate and re-prioritise the whole list every turn, or let the agent declare itself done without verification.

Marketing frameworks and the marketing-agent packages agree on a generic foundations order: understand the situation and customer before setting positioning, positioning before offer and messaging, and those before channels and tactics. That order can be planned by the agent itself as ordinary tasks with dependencies; none of the packages needs per-activity structure to express it, and none of them actually holds a cross-session task plan. Corey Haines' marketing-plan skill comes closest, with a progress.md state machine and a resumption decision tree that infers state from which files exist.

For the task store, a YAML file of tasks, extended with a dependency link and a small set of work statuses and paired with a deterministic query-and-check script, fits best. Its main advantage is that a task's parent can stay the frame it serves while order is a separate link; Hermes Kanban and Linear both conflate those or force a second authority. Hermes Kanban is the natural later addition when the agent needs unattended execution; Linear is the weakest fit for a packaged method because every other owner would need a Linear account.

1. Marketing planning practice

SOSTAC

Evidence. PR Smith's SOSTAC, developed in the 1990s and formalised in his 1998 Marketing Communications, sequences any marketing plan as Situation (where are we now), Objectives (where do we want to be), Strategy (how do we get there), Tactics (the details of strategy), Action (who does what, when) and Control (how we measure and adjust) (Wikipedia, Smart Insights, Dave Chaffey). Control feeds the next situation analysis, so the model is a cycle rather than a line. SOSTAC is a registered trademark of PR Smith (Businessballs).

Interpretation. SOSTAC maps onto the agent's levels: Situation is evidence, Objectives are marketing goals, Strategy is approaches, Tactics are campaigns and routines, Action is tasks, Control is the weekly review and campaign close. It says nothing about how to choose among concurrent tasks; it is a planning sequence, not an execution loop.

OKRs: the weekly check-in and the quarterly cycle

Evidence. Christina Wodtke's four-square, introduced in Radical Focus, puts on one page the team's priorities for this week, the OKRs with a confidence rating for each key result, a forecast of the coming weeks, and health metrics that must not degrade (Michael Goitein, Miro template). Wodtke's O'Reilly Introduction to OKRs describes a Monday commitment meeting in which each person reports how their confidence has changed, with confidence recorded out of 10 (O'Reilly, chapter 4). She is quoted as saying "the cadence is more important than the quality of the OKR" (Goitein, above). The Friday "wins" session is widely attributed to Radical Focus but was not verified against the book. Google's re:Work guide sets OKRs quarterly and scores them from 0 to 1, with 0.6 to 0.7 treated as good for ambitious goals (re:Work; not re-fetched).

Interpretation. The four-square is the bridge between goals and work that the agent's design lacked: once a week, confidence per key result decides the next week's priorities, and health metrics (the routine KPIs) act as guardrails. The weekly priorities list is the human-visible artefact of work selection.

Agile marketing

Evidence. The Agile Marketing Manifesto states five values: "Focusing on customer value and business outcomes over activity and outputs", "Delivering value early and often over waiting for perfection", "Learning through experiments and data over opinions and conventions", "Cross-functional collaboration over silos and hierarchies" and "Responding to change over following a static plan" (agilemarketingmanifesto.org). Practitioner guidance for marketing teams is to start with a single prioritised backlog, make the work visible on a board, add work-in-progress (WIP) limits, and only then experiment with sprints; Kanban is described as continuous, pull-based flow with WIP limits, and Scrumban as sprints plus a Kanban board (MarketingProfs, Adobe guide, Umbrex). These are secondary sources of mixed quality.

Interpretation. For a single agent with no team, the useful parts are the single ranked backlog, the definition of done, and a WIP limit; sprint ceremonies add nothing that the weekly review does not already provide. Pull-based flow (take the next ready item when the current one finishes) matches how an agent session works.

Prioritising across competing goals

Evidence. Sean Ellis's ICE scores each idea on impact, confidence and ease (Sean Ellis); Intercom's RICE adds reach and divides by effort (Intercom; not re-fetched). Corey Haines keeps one shared experiment backlog ranked by ICE and warns "Don't let each loop run its own tests" (marketing-loops/references/loop-orchestration.md). His loop rollout path is explicitly staged: "Foundation before growth", "One at a time", "Cap the total", "Re-audit quarterly" (same file).

Interpretation. Scoring formulas rank ideas within one backlog; they do not settle which goal deserves effort. Practice settles that at the goal level (OKR confidence, foundation-first staging) and only then ranks within. An agent needs the same two tiers.

What persists between cycles

Evidence and interpretation combined: the plan document (SOSTAC), the OKR set with scores and confidence history, the backlog with statuses, campaign post-mortems and learnings (Corey Haines' Learnings table), and the health metrics. The weekly priorities list is regenerated each week; the backlog persists.

2. Agent planning and execution patterns

Anthropic's long-running agent harness

Evidence (Anthropic, "Effective harnesses for long-running agents", fetched). The problem is that "each new session begins with no memory of what came before", and compaction alone was not enough. An initializer session with a different prompt sets up the environment: an init.sh, a claude-progress.txt log, a first git commit and a feature list. Each later session runs a fixed routine: check the working directory, read the git log and the progress file, read the feature list and pick the highest-priority unfinished feature, start the environment and run a basic end-to-end test, implement one feature, then commit and update the progress notes. The feature list is JSON, each entry with a category, description, test steps and a passes boolean, all initially false; agents may change only passes, and "It is unacceptable to remove or edit tests". JSON was chosen because the model is less prone to rewrite it inappropriately than Markdown. Agents are told to "work on only one feature at a time". Observed failures: trying to one-shot the whole job, leaving undocumented half-work when context ran out, declaring the project done too early, and marking features passing without proper testing.

Interpretation. Three separate artefacts do three jobs: a structured, append-only-in-spirit list of items (the plan), a free-text log (what happened and why), and version history (proof and undo). Two of its rules matter as much as the files: the rule that a session works on one item and verifies it before marking it done, and a structural guard against the plan being rewritten (only status fields may change).

Claude Code tasks

Evidence. In January 2026 Claude Code replaced its in-session to-do list with Tasks, which carry dependencies, are stored on disk under ~/.claude/tasks, persist across compaction, and can be shared between sessions by setting CLAUDE_CODE_TASK_LIST_ID; updates broadcast to other sessions on the same list (ClaudeLog, Dale Seo, claudefa.st). The earlier to-dos lived in session memory and were lost on /clear. These are secondary sources; Anthropic's own announcement was not fetched.

Interpretation. The vendor's own move was from an in-context checklist to a file-backed task graph with dependencies, precisely to survive session breaks. Hermes's to-do tool is the in-session kind and would not survive.

Manus and plan recitation

Evidence. Manus reports that its agent keeps a todo.md and rewrites it as it works, which pushes the objective into the most recent part of the context and counters drift on long tasks (Manus, "Context Engineering for AI Agents"; from prior knowledge, not re-fetched).

Interpretation. Re-reading the plan at the start of each step matters as much as storing it. A loading rule that brings in the current frame in detail and the enclosing frames as summaries is a form of recitation.

LangGraph persistence

Evidence. LangGraph's durable execution saves a checkpoint after each step under a thread ID; resuming means invoking again with the same thread ID, and execution restarts from the last checkpoint rather than the exact line, so side effects must be wrapped to be idempotent (LangChain docs, checkpointers). Its plan-and-execute pattern separates a planner that writes a step list from an executor that works through it, with a re-planner after each step (LangChain blog, 2023; from prior knowledge, not re-fetched).

Interpretation. Checkpointing graph state solves resume for a program, not for an agent whose plan is itself a judgement. The transferable lessons are idempotent side effects (do not post twice after a crash) and a re-plan step after each executed step, which should be allowed to add or drop tasks but not to rewrite finished ones.

BabyAGI-style queues and why they failed

Evidence. BabyAGI loops: take the top task, execute it, generate new tasks from the result, re-prioritise the whole list. Reported failures include re-adding completed tasks and so looping, and AutoGPT's unbounded loops became the canonical example; proposed fixes are objective stop conditions, turn or time caps, stall detection and structured failure returns that escalate (SEP, Jina AI, Hackernoon). A widely repeated 30 to 40 per cent success-rate figure for AutoGPT could not be traced to its study and is not used here.

Interpretation. The failure was not the queue but three properties of it: the queue lived in memory, the model regenerated and re-ranked everything every cycle, and nothing outside the model judged completion or stopped the loop. The Anthropic harness inverts each one.

What distinguishes plans that survive a session break

Interpretation drawn from the evidence above. A plan survives when it is (a) in a file, not the conversation; (b) made of discrete items with machine-checkable status, not prose; (c) edited only at status and new-item level, never rewritten wholesale; (d) paired with a progress log and version history so the next session can verify rather than trust; (e) worked one item at a time with a "done" that requires proof; and (f) read at the start of every session by a fixed routine.

How work selection is done

Evidence. Three mechanisms appear: a priority-ordered list where the agent takes the top unfinished item (Anthropic harness, BabyAGI); a dependency-driven scheduler that promotes items whose prerequisites are done (Hermes Kanban's dispatcher; Claude Code Tasks); and human approval of a plan or a week's priorities (OKR Monday commitments; Marketing Agent OS's rule that approval is never inferred).

Interpretation. These combine rather than compete: dependencies decide what is eligible, priority decides among eligible items, and a human approves the priorities at a slower cadence rather than each task.

3. The marketing-agent packages

Marketing Agent OS

Evidence (skills/marketing-os/SKILL.md, 78 lines). The router classifies a request "by objective, funnel stage, channel, artifact, and decision horizon", routes "to the smallest set of specialist skills", requires that "for cross-channel work, establish the narrative/claims truth before producing publish-ready downstream assets", and says "Run specialists in parallel only when their inputs are independent. Otherwise sequence by dependency." Handoffs carry a status (DONE, DONE_WITH_CONCERNS, BLOCKED, NEEDS_INPUT), open loops and up to three recommended_next_skill. Its control artefacts (references/control-artifacts.md) apply "when work crosses skills, spans multiple turns, or can produce a persistent or real-world side effect", keep proposal, approval, execution, receipt and measurement separate, use the lifecycle proposed → approved → executing → complete plus blocked, require an idempotency key, and state "Approval is never inferred from elapsed time".

Interpretation. "Sequences dependencies" is a one-line instruction to the model, not a mechanism: there is no stored plan, no dependency field and no resume procedure. The useful parts are the handoff status vocabulary, the narrative-before-downstream rule, and the control-artefact lifecycle for side-effecting tasks.

Aaron Marketing Skills

Evidence (docs/system-architecture.md, commands/auto.md). Four layers: L1 strategy (narrative, always-on), L2 channels (always-on engines), L3 orchestration (launches, episodic), L4 protocol (registries and memory). "Canonical logical order: narrative → seo-geo → social → email → ad → influencer → launch → protocol." Each of seven disciplines has four fixed phases. Downstream builders must carry a dependency_status of verified, approved-fallback or blocked against the narrative canon. The /auto front door parses a goal, picks "the smallest" phase or chain, asks only for blocking inputs and "continue[s] to the natural stopping point"; its --deep mode first outputs "a phase plan, success criteria, evidence inventory, risk gates, permission checkpoints, and stop condition". Progress lives in a capped hot cache and a 40-line session checkpoint treated as an "untrusted hint".

Interpretation. Aaron sequences by a fixed discipline order and fixed phase order, which is the per-activity structure the agent's design set out to avoid, but it confirms the foundations-first order (narrative before channels) and enforces it with a dependency status rather than trust. The --deep phase plan is a good template for a planning task's output.

Corey Haines' marketingskills

Evidence. product-marketing says to "Use this at the start of any new project before using other marketing skills". marketing-plan runs three phases (INIT, REVIEW, FINALIZE) and keeps progress.md with phase, current_section, plan_version, last_updated, a checklist of sections, approved artefacts and notes; its resumption decision tree checks state "in that order on every invocation" from which files exist, and a finalised plan is "never silently overwritten" (references/methodology.md, steps 1.1.1 and 1.1.2). marketing-loops/references/loop-orchestration.md layers loops as sensing, diagnostic, action and learning, makes "weekly-marketing-review ... the router" that "dispatches each notable mover to the loop that owns it", and stages adoption from foundation (tracking and weekly review) to compounding. Every loop must declare "State / idempotency", called "Non-negotiable for anything scheduled".

Interpretation. Two borrowable patterns: resume from state the files can prove (a checklist plus artefacts that exist), and the weekly review as the router that turns metrics into the next work. Both are generic. The progress.md is per deliverable, not a cross-goal plan.

Anthropic's knowledge-work marketing plugin

Evidence (marketing/skills/campaign-plan/SKILL.md). The skill produces a campaign brief with a week-by-week content calendar with columns Week, Content Piece, Channel, Owner/Notes and Status, advises "Start with milestones", and lists dependencies and risks. It holds no state beyond its output.

Interpretation. A plan is an output document, not a tracked object. Useful only as the output shape of a campaign-planning task.

Across the packages

Interpretation. None of the four holds a durable cross-session task plan with dependencies and statuses, and none chooses between competing goals. All four agree on foundations first (shared context or narrative before downstream work). An agent using them has to supply the orchestration itself; the packages supply methods for individual tasks.

4. Task store choice

The three candidates, against the criteria the design set. Hermes Kanban facts are from the earlier review of the Hermes code. Linear facts are from Linear's public product, not re-verified: issues with workflow states, sub-issues, "blocked by" relations, projects, a GraphQL API and mobile apps.

Criterion	Tasks in YAML	Hermes Kanban	Linear
Agent reads and writes reliably	Yes with a script; raw whole-file edits by the model are the main risk	Yes once the kanban toolset is enabled for Telegram; worker protocol enforces complete, review or block	Yes through the API and a Linear skill; network and rate limits apply
Survives session breaks	Yes; file plus daily git commit	Yes; SQLite on the host, with events and attempt history	Yes; hosted
Owner can see and steer	Only through the agent's Telegram reports or a separate view; no native view	Telegram notifications of terminal events (not exactly-once); hermes kanban CLI; no phone view noted	Best: phone app, comments, reprioritise by drag
Portable to other Hermes owners	Best; ships as an empty template with the package	Good; native to every Hermes install, single host only	Weak; each owner needs a Linear workspace and key
Parent means the frame served	Yes; order can be a separate link	No; parent and child mean dependency order	Partly; sub-issue parent is containment, but frames would have to be mirrored as projects or labels
Separates execution state from goals and evidence	Only if tasks move to a file of their own	Yes, by construction	Yes, by construction
Unattended execution	None; needs cron or a heartbeat to start sessions	Dispatcher runs ready tasks every 60 seconds, reclaims stale claims, retries	None
One authority	Yes	Needs sync with the goal records if frames stay there	Needs sync with the goal records

Interpretation. Kanban and Linear each separate execution state well, but each makes tasks a second authority whose links to frames must be kept in step with the goal records. YAML keeps one authority and ships with the package, at the cost of owner visibility and of building a small query script.

Implications

What follows is a proposed shape for an agent's planning loop, drawn from the evidence above. It has not been tested on real work.

A plan need not be a new kind of record. It can be a set of tasks under the frame they serve, with two additions to each task: an after link listing tasks that must be done first, kept distinct from the parent so the parent still means "the frame this serves"; and a work status from a small fixed set (proposed, ready, active, waiting, done with proof, dropped with a reason). Each task also names its method, the procedure or adapted package skill it will follow, so the choice of method is recorded and reviewable. Planning is itself a task, done when its subtasks exist with after links and methods and the owner has agreed them. The research behind the order (customer research before positioning, positioning before offer, both before channel selection, which SOSTAC, Corey Haines, Aaron and Marketing Agent OS all support) is cited as evidence on that planning task. Re-planning adds or drops tasks with reasons and never edits a done task, following the Anthropic harness's rule that only status may change.

A fixed next-work rule, run at the start of every session and after each task finishes, makes the choice reproducible rather than a fresh judgement each time:

1. A waiting task whose condition is now met (the owner has replied, a date has passed) becomes ready.
2. A routine that is due by its cadence runs first, because routines carry the KPIs treated as guardrails.
3. Otherwise take the highest-ranked ready task in the frame named by the current-work section, finishing what is in hand.
4. If that frame has no ready task, take the highest-ranked ready task under the goal ranked first in this week's priorities.
5. If nothing is ready, the next task is to plan: create the missing subtasks, or raise to the owner what blocks progress.

flowchart TD
  S["Session start or task finished"] --> W["Promote waiting tasks whose condition is met"]
  W --> R{"Routine due?"}
  R -- yes --> RR["Run the routine"]
  R -- no --> F{"Ready task in current frame?"}
  F -- yes --> FT["Take highest-ranked ready task there"]
  F -- no --> G{"Ready task under this week's top goal?"}
  G -- yes --> GT["Take highest-ranked ready task there"]
  G -- no --> P["Plan: add subtasks or raise the blocker to the owner"]

Only one task is active at a time (the harness's one-item rule, agile's WIP limit). Ranking across goals is set at the weekly review, where the agent proposes the week's priorities in four-square form and the owner confirms or reorders them; within a frame, ICE is enough. Each session then follows a fixed routine modelled on the Anthropic harness: read the current-work section, run a check script over the task file, apply the rule, work one task, record its proof, rewrite the current-work section and append one dated line to a progress log. Side effects such as publishing follow Marketing Agent OS's separation of proposal, approval, execution and receipt, and are marked done only on a receipt.

For the task store, the evidence favours YAML in a file of its own, separate from the goal and evidence records but sharing their IDs, parent rules and post-write check. Goals, approaches, evidence and decisions change weekly at most; tasks change many times a session, so separating them means a bad task write cannot damage evidence and keeps the goal records small enough to load. A small script does the reading and writing (list ready tasks, set a status, add a task, validate), so the model never hand-edits YAML, which addresses the Anthropic harness's concern about models rewriting plan files. Hermes Kanban becomes worth adding when the agent needs tasks to run unattended between conversations: its dispatcher, claims and retries are what the YAML file lacks, and the YAML can stay the authority while ready tasks are pushed to Kanban for execution. Linear is the weakest fit as the store, because it ties a packaged method to a third-party account and creates a second authority.

Gaps

• Wodtke's own wording on the four-square quadrants and the Friday wins session was not read from Radical Focus; descriptions come from secondary sources and the O'Reilly chapter summary.
• Google re:Work, Intercom's RICE post, Manus's context-engineering post and the LangChain plan-and-execute post are cited from prior knowledge and were not re-fetched.
• The Agile Marketing Manifesto's principles (as distinct from its values) were not retrieved.
• Claude Code Tasks are described from secondary sources; Anthropic's announcement was not fetched.
• Linear's feature details (relations, mobile app, API limits) were not re-verified.
• Hermes Kanban was not re-inspected; whether a Kanban board can be viewed on a phone, and how cleanly a push from the task file to Kanban would work, are open.
• No source was found that evaluates agent-run marketing plans over weeks; all agent evidence comes from coding harnesses.
• The next-work rule and the separate task file are proposals, not tested on real work.