4 Real AI Agent Automation Examples: Hand Off Goals, Not Chats

When you work with AI agents like Claude Code or Codex, you usually end up sitting in front of the terminal, giving instructions one turn at a time. This post covers four examples of AI agent automation where you just hand over a goal and the agent does the work, plus the patterns those examples have in common.

First, a confession. In March 2026, I designed a pipeline where you drop an idea file into a folder, a PM agent splits it into tasks, and developer agents carry them out. That design never actually worked. So this time, instead of my own design, I picked only examples that run today and that you can verify in public documentation.

Assigning Work by Chat vs. by Goal#

When you assign work through terminal chat, you have to stay put. Every time the agent finishes a step, you give the next instruction, check the result, and instruct again.

Assigning work by goal flips that order. You write down what you want and what "done" means in an issue or a file, then walk away. The agent reads it, does the work, and hands back the result as a PR or a log.

Example 1: Assign an Issue, Get a PR Back#

The easiest place to start is handing a GitHub issue to an agent. You pass the issue to the agent the way you'd pass it to a teammate, and the agent creates a branch, does the work, and comes back with a PR.

Assigning an Issue to GitHub Copilot#

GitHub Copilot starts working when you pick Copilot under the issue's Assignees. According to the official docs, Copilot starts the task, raises a pull request, and requests your review when it's done. If you need changes, mention @copilot in a PR comment.

One caveat in the docs stands out: Copilot doesn't see comments you add to the issue after assigning it. So before you assign, put everything in the issue body: the outcome you want, the patterns to follow, testing requirements, and the files it must not touch. Also, by default, GitHub Actions workflows don't run automatically when Copilot pushes to the PR. A human has to review the changes and click Approve and run workflows.

Calling @claude with Claude Code GitHub Actions#

Claude Code GitHub Actions runs Claude Code inside your repository's workflows. Mention @claude in an issue or PR comment, and Claude analyzes the code, implements the change, and pushes commits. For setup, run /install-github-app in Claude Code and it walks you through installing the app, adding the secret, and opening the workflow PR.

@claude implement this feature based on the issue description
@claude fix the TypeError in the user dashboard component

If you put a CLAUDE.md at the repository root, Claude follows the code style and rules in it when it creates PRs. It's like moving the rules you used to explain in every chat into a single file.

Example 2: Agents That Start Work on a Schedule#

Even issue assignment still means a human pressing "do it now." For recurring work, you can hand the trigger itself to a schedule.

Scheduled Runs with Claude Code GitHub Actions#

When you add a prompt to the workflow, Claude Code GitHub Actions runs in automation mode without waiting for a mention. Pair it with a cron schedule and it starts on the same goal at the same time every day. Here's the example from the official docs, which summarizes yesterday's commits and open issues at 09:00 UTC daily.

name: Daily Report
on:
  schedule:
    - cron: '0 9 * * *' # Every day at 09:00 UTC
jobs:
  report:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: read
      id-token: write
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          # This line is the goal you give the agent
          prompt: "Generate a summary of yesterday's commits and open issues"
          # Allow only the tools the goal needs
          claude_args: |
            --allowedTools "mcp__github__list_commits,mcp__github__list_issues"

With only a prompt, Claude can't use the shell or the GitHub API. You have to grant the tools the goal needs with --allowedTools. To keep costs down, the docs suggest capping iterations with --max-turns and setting a workflow timeout.

Runbooks in Multica Autopilots#

Multica, which I currently use to manage agent work, has Autopilots that fill the same role. Each autopilot holds a Runbook describing the goal, background, constraints, and steps, along with an assigned agent and its triggers.

There are three trigger types: a schedule, a webhook from an external system, and a manual run. When a trigger fires, Multica either creates an issue and assigns it to the agent, or runs the agent directly without an issue. The docs' examples include a weekly customer feedback roundup every Monday at 09:00, a daily progress summary, and periodic dependency checks.

Example 3: The Ralph Loop Keeps Feeding the Goal File#

Ralph is a technique Geoffrey Huntley introduced in July 2025. At its core, it really is a one-line Bash loop.

# Feed the same goal file to the agent, over and over
while :; do cat PROMPT.md | claude-code ; done

Each time the loop runs, the agent starts with a fresh context. So memory lives in files, not in the conversation. Every loop reads the same things the same way: specs written beforehand through conversation (a specs folder, one spec per file), a prioritized to-do list in fix_plan.md, and AGENT.md with build instructions.

Huntley stresses these rules:

• One thing per loop — Handle only the single most important item from the to-do list.
• Backpressure — Use tests, static analysis, and type checking to reject bad output.
• Track progress in git — Commit finished work, and tag a release once builds and tests pass.
• When it goes wrong, fix the prompt — If the agent keeps making the same mistake, add "signs" to the prompt instead of blaming the tool.

That said, Huntley himself says Ralph works best for greenfield projects and that he wouldn't use it in an existing codebase. He also pushes back on claims that engineers are no longer needed.

Example 4: Harnesses for Work That Takes Hours#

In November 2025, Anthropic published a post on its engineering blog about harnesses for long-running agents. When they tried to have an agent build a full web app from a single high-level prompt, it failed in two ways.

1. It tried to build too much at once, ran out of context, and left features half-finished with no record.
2. An agent in a later session saw what had already been built and declared the project done.

The fix was to split the agent into two roles.

• Initializer agent — Runs only in the first session. It creates init.sh to start the dev server, a progress log called claude-progress.txt, and an initial git commit. Then it writes a feature list in JSON based on the spec.
• Coding agent — Runs in every session after that. It reads the progress log and git history, then implements only one feature: the highest-priority one that isn't passing yet.

Each item in the feature list looks like this. In the claude.ai clone example, there were over 200 of these, and every one started as passes: false.

{
  "category": "functional",
  "description": "Feature description",
  "steps": ["Verification step 1", "Verification step 2"],
  "passes": false
}

The coding agent may only change the passes value. According to the post, they chose JSON because models are less likely to inappropriately edit it than Markdown. Agents also often marked features done after only unit tests or curl checks, but results improved a lot once they were told to verify by actually using the app like a human, through browser automation.

What the Working Examples Have in Common#

Put the four examples side by side and the approach boils down to a few patterns.

1. Write the goal completely in one place — An issue body, a prompt, a Runbook, or PROMPT.md. Anything you add after handing it off may never reach the agent.
2. Assign one thing at a time — Ralph does one item per loop; Anthropic's harness does one feature per session.
3. Keep memory in files and git, not in the conversation — To-do lists, progress logs, and commits become the starting point for the next run.
4. Decide "done" by verification, not by the agent's word — Tests, type checks, passes flags, and browser verification do that job.
5. Keep the human in the review seat — PR review requests, run history, and workflow approval all leave a checkpoint for a person.

Why My Idea-to-Task Design Didn't Work#

My March design had you write an idea in docs/ideas/; a PM agent watching that folder would create task files in docs/tasks/, and an assignment engine would hand them out to developer agents. When I actually built and ran a similar Markdown-based automation, the picture of "just write a note and everything else happens" never materialized. I wrote up the problems with result quality, management overhead, and pipeline maintenance in What to Get Right When Automating AI Agent Work with Markdown.

Compared with the examples above, the difference is clear. The examples sit on top of tools that already exist, like GitHub issues, Actions, and git, and they have a clear mechanism for deciding when work is done. My design required building new pieces: a folder watcher, a PM agent, and an assignment engine. The task files also only said what to build; they had no completion criteria or verification method for deciding when the work was done.

How to Start Small#

You don't need to build a pipeline from day one. Connect Claude Code GitHub Actions or Copilot to one repository, then take what you used to explain in terminal chat and move it into a single issue that includes completion criteria. For writing issues as good briefs, you can reuse the goal, context, completion criteria, and don'ts structure from Using Obsidian Notes as Work Orders for AI Agents.

Be a good listener. Your ears will never get you in trouble.

— Frank Tyger