AI Agent Examples: 7 Workflows That Produce Real Artifacts

Useful AI agent examples show an operating contract you can inspect. Each example needs a trigger, approved sources, a named artifact, an action boundary, a verifier, a recorded failure state, an escalation point, and a limit on autonomy. Without those parts, you have a prompt demo. With them, you have a workflow that can earn more responsibility.

The seven examples below come from the internal operating system in my repository. They describe controlled evidence and sanitized artifact shapes. No customer deployment is implied, and no private record appears in the examples.

Recent practitioner threads question whether production agents are mostly hype and describe false-success reporting, permission-boundary violations, and unreliable tool execution as recurring failures. That skepticism is useful. I call the polished descriptions that hide those gaps AI slop.

Each one follows the same context-to-output loop: approved source context, a scoped task, a tangible artifact, a deterministic check, then human escalation when evidence or authority runs out. The system supports judgment. It does not replace the person responsible for the consequence.

The AI agent workflow guide gives you the reusable card behind these examples: context source, task, output, verifier, and escalation rule.

Quick verdict: Give an agent one role and a narrow job. Put versioned skills around the job, allow only named tools and sources, require a durable artifact, then add a gate that can block the run. Let the agent proceed automatically while evidence stays inside the contract. Stop before external communication, publishing, sensitive data changes, money, or a decision reserved for a person.

Agent, skill, tool, artifact, and gate

• Agent or role: the component responsible for one bounded job. It chooses the next permitted step and coordinates the workflow.
• Skill: a versioned procedure that tells the role how to perform a recurring task, which sources to trust, and where to stop.
• Tool or source: the interface used to read or change a system. Search Console, Ahrefs, Gmail, GitHub Issues, a transcript directory, and a database table all belong here.
• Artifact: the durable result. It may be a brief, draft, decision record, status report, evidence manifest, or HTML email.
• Gate: a deterministic check or required human decision that blocks the next state when evidence is missing or authority is absent.

A model may write text inside these workflows, but the surrounding contract defines its authority. Start with how to build a Second Brain AI agent for that layer. The coding agents guide for knowledge workers places the pattern beyond software teams.

Artifact gallery: seven context-to-output workflows

Workflow	Approved source context	Scoped task	Tangible output	Deterministic check	Human escalation
Research brief	Issue, approved brief, GSC, Ahrefs, and route inventory	Decide the action and canonical owner	SEO handoff record	Dated evidence manifest plus canonical and rendered-page checks	Conflicting owner, missing evidence, or unclear product bridge
Meeting to decision	Transcript, Calendar event, attendee metadata, and existing meeting row	Separate recorded facts from decision candidates	Meeting row and decision candidate	Transcript identity, event identity, confidence, and collision checks	Ambiguous speaker, weak identity match, or official decision
Client update	Canonical Gmail thread, CRM eligibility, approved facts, and verified resources	Draft an update without inventing commitments	Evaluated email draft and commitment ledger	Eligibility, thread, resource, body-header, and voice checks	Missing owner, date, recipient, or send permission
Content QA	Approved brief, article source, facts, links, and voice rules	Evaluate one exact content snapshot	Draft, score, and content hash	Structure, links, voice rules, and hash equality	Semantic judgment, approval, and publication
Account research	Persona, CRM identity, public evidence, exclusions, and prior messages	Exclude, verify, score, and queue a draft	Research record and pending executive action	Identity, fit, article, thread, and exclusion checks	Ambiguous identity or any outreach send
Project status	Live GitHub Issues, repository activity, and validation receipts	Separate planned, changed, verified, and shipped states	Source-backed status synthesis	Issue links and receipts for each claimed state	Changing priority or claiming shipment without live proof
Operating review	Dated receipts, metric definitions, issue state, and trust signals	Surface evidence, conflicts, and what to trust less	evidence.json, email.html, and trust review	Source index, freshness, integrity, voice, and render checks	Send, retirement, promotion, or another protected action

1. Research brief: an SEO new-asset decision

The trigger in this example is GitHub issue #2480, which asks whether /p/ai-agent-examples should become a distinct canonical page. The responsible role is the SEO decision layer running in new-asset mode. Its job is to decide the smallest justified action. The $seo skill does not write the public article. It hands an approved direction to /content, which routes writing to /publish-blog.

Approved inputs follow a strict order: the issue and brief, target URL, open owner issues, published route inventory, Search Console, Ahrefs, and a live rendered-page or search-results check. Together they show current demand, Google's existing URL association, market competition, and possible cannibalization.

For this article, the September 5, 2026 Ahrefs Keywords Explorer check showed an estimated 2,100 monthly searches in the United States, 5,400 globally, keyword difficulty of 11, and traffic potential of 1,200. The bounded 90-day Search Console export did not contain the exact query in its returned rows. I recorded that source as partial instead of claiming zero demand or zero existing visibility. Those two receipts supported a create decision only after the content inventory showed that the proposed page served a different reader job from the existing build, evaluation, and shared-memory guides.

The run proceeds step by step:

1. Read issue #2480 and inspect the proposed canonical URL.
2. Search open issues, active briefs, and published routes for an existing owner of the same reader job.
3. Read current Search Console and Ahrefs evidence with its date, window, and availability.
4. Compare the query intent with existing pages and record create, refresh, expand, defend, consolidate, or ignore.
5. Return the required SEO handoff. Only an approved handoff enters the writing pipeline.

Sanitized example schema, illustrative only:

mode: new-asset
action: create
canonical_owner_url: /p/ai-agent-examples
query_family: ai agent examples
evidence_manifest:
  - github_issue
  - gsc_snapshot
  - ahrefs_snapshot
  - published_route_inventory
  - rendered_page_check
cannibalization_decision: distinct_reader_job
recommended_writer: publish-blog
blocked_gates:
  - exact_snapshot_approval

A second research workflow shows why the source boundary matters as much as the summary. In September 2026, the Brief Builder evidence pipeline normalized 389 source records into 224 answer-bearing canonical submissions. The primary completed, non-test set contained 132 submissions. Purpose and ownership rules allowed detailed analysis of 87 submissions inside my creator scope and quarantined 45 from another creator tenant. Technical access to all 132 records did not create authority to analyze all 132.

The artifact did not claim market prevalence. It recorded what to reuse, reject, and defer. It reused the existing initiative structure, rejected keyword counts as sufficient product evidence, and deferred public UI, CRM writes, prices, and live integrations. This narrower conclusion was more useful than a bigger unsupported claim.

The deterministic verifier checks that every evidence item has an as_of date, scope, and availability state. It also checks canonical ownership and rendered substance. Missing or stale data becomes blocked-by-evidence, never a zero that makes the opportunity look weak. A conflicting canonical owner, an unavailable source, or an unclear product bridge goes back to Iwo for a decision.

Allowed side effects end with a structured handoff and an approved brief. The SEO role cannot write metadata, create a competing route, publish content, submit IndexNow, or change the database. That split keeps research from quietly becoming publication.

2. Meeting to decision: sync first, confirm second

The trigger is a new OpenOats transcript inside the approved sync window. The meeting intelligence role uses /sync-meetings to connect the transcript with calendar metadata and store structured extraction in meeting_intelligence. A separate /decision-documentation path records a material decision only after a person confirms what was decided.

Approved inputs are the transcript, its timestamps, same-day calendar events, attendee metadata, destination identity, and any existing meeting row. The transcript path acts as the ingestion key. The calendar event identifies the scheduled meeting. Manual links and reviewed fields survive later syncs.

The run looks like this:

1. Start in check mode and display the account, transcript root, date window, calendar identity, destination, and files in scope.
2. Remove transcripts that already have a verified receipt.
3. Match each remaining transcript to a calendar event using time overlap and a recorded confidence value.
4. Classify an unmatched transcript as ad_hoc with no automatic attendee link.
5. Extract summary, candidate actions, candidate decisions, follow-up commitments, and sentiment.
6. Upsert one meeting, then verify the returned row before moving to the next.
7. If Iwo confirms a material decision, /decision-documentation records context, options, chosen direction, expected result, confidence, review date, and the stop or double-down condition.

Sanitized example schema, illustrative only:

meeting:
  source_type: openoats
  meeting_type: ad_hoc
  calendar_match: none
  match_confidence: 0
  extracted_decisions:
    - status: candidate
      text: redacted_example
decision_record:
  official: false
  chosen_option: pending_human_confirmation
  outcome_rating: unknown

The verifier is the returned meeting row with its transcript identity, event identity when present, confidence, and updated time. A transcript collision or material transcript change records a review state instead of overwriting blindly. Low-confidence name matching cannot attach the meeting to a person. The meeting owner handles ambiguous speakers, missing calendar context, or conflicting interpretations.

This workflow may write the bounded meeting record because that side effect belongs to the invoked sync skill. It may later write a decision record after explicit confirmation. It may not turn extracted language into an official decision, assign work, contact attendees, or auto-link a weak identity match. Extraction provides a candidate. Human confirmation supplies authority.

3. Client-update draft: evaluated, never sent by the drafting run

The trigger is a request for a client update or reply. The email-writer role composes the message through /draft-email, /evaluate-email, and the Iwo Voice gate. The artifact is the draft plus its thread, routing, eligibility, resource, and evaluation receipts. The drafting run ends before transport.

Approved inputs come from the prospect record, recent activity, channel preference, delivery and consent state, canonical Gmail thread, newest human message, approved product facts, and verified resources. The actual thread outranks stored summaries. New inbound context replaces an old follow-up plan.

One internal product test started with five rough sentences about a possible launch delay. No date had been agreed. One engineering check had an owner, while the customer update had no owner, recipient, or sending time. The artifact kept those differences visible instead of smoothing them into a confident email.

The run follows these checks:

1. Confirm the recipient is eligible and the chosen channel matches their preference.
2. Read activity history for bounce, unsubscribe, merge, test-record, purchase, and routing conflicts.
3. Resolve the canonical Gmail thread. CRM-only history without a matching thread becomes a hold, not permission to open a new conversation.
4. Read the newest human message before drafting a reply.
5. Verify any named guide, page, coupon, product fact, or checkout link before mentioning it.
6. Draft the update from verified facts, then run the email evaluator and medium-severity Iwo Voice validator.
7. If a body file will be used later, scan it for accidental Subject, To, From, Cc, or Bcc lines. Headers belong to transport arguments, not the message body.

Sanitized example schema, illustrative only:

route: context_only
thread_state: canonical_reply
recipient_eligibility: passed
latest_human_message_read: true
resource_check: not_used
body_header_gate: passed
evaluation: passed
commitment_ledger:
  launch_date: no_decision_agreed
  next_week: unconfirmed_possibility
  engineering_check:
    owner: confirmed
    deadline: not_stated
  customer_update:
    owner: unassigned
    timing: not_stated
status: draft_for_review
transport_authorized: false

The accompanying message was titled Launch timeline update. It said that the timeline was under review and that no revised date had been agreed. The recipient and sender remained placeholders, and the status stayed draft only. The test passed because uncertainty survived the transformation.

The deterministic gates reject a bounced or unsubscribed recipient, a wrong channel, a missing thread for an existing conversation, a repeated or unverified resource, raw headers in the body, and several known voice failures. A quality score cannot overrule an eligibility failure. New inbound context, uncertain identity, or a Factory-related route goes to a person for review.

Allowed side effects include reading approved records and producing an evaluated draft. Depending on the owning queue, the draft may be stored as pending work. The role may not send, create a disconnected follow-up thread, invent a resource, expose research that the recipient could not reasonably understand, or promise scope and dates absent from the source record.

4. Content QA: this article as the artifact

This article supplies a concrete content QA example. GitHub issue #2480 triggered /publish-blog, with the essay writer producing the source and the evaluator checking its quality. Iwo Voice supplied the public-copy ban list. The first draft passed the medium-severity voice validator and received an evaluation score of 81 out of 100.

The exact snapshot still lacked approval because it described plausible workflows without enough repository grounding. Its approved content hash remained null. The passing score showed that a rubric threshold was met. Approval separately binds Iwo to the exact content that would be published.

The content run proceeds through distinct states:

1. Read the issue, SEO handoff, voice rules, source material, and related-page inventory.
2. Draft the markdown source and include the required answer block, table, examples, internal links, and FAQ.
3. Run deterministic voice checks, link checks, structural checks, and an independent content evaluation.
4. Store or display the exact snapshot with its score and content hash.
5. Withhold approval when the evidence, specificity, or voice still misses the brief.
6. After any edit, calculate a new hash and run the gates again.
7. Only Iwo can approve that exact snapshot for the later publication path.

Sanitized artifact receipt from this workflow:

status: draft
voice_validator: passed
evaluation_score: 81
approval_state: withheld
approval_reason: repository_grounding_too_general
approved_content_hash: null
next_action: rewrite_and_re_evaluate

The deterministic verifier checks banned phrases, required structure, links, snapshot identity, and hash equality. The semantic evaluator grades quality, but cannot grant approval. Every content edit invalidates an earlier approval hash because the approved object has changed. The guide to evaluating agent skills explains why deterministic assertions and semantic judgment need separate roles.

This workflow may edit the source article and generate evaluation artifacts. It may not mark itself approved, publish, submit indexing, or treat 81 as authorization. The recorded failure state stays draft with approval withheld until Iwo accepts the exact snapshot.

5. Approval-gated account research: queue the action, never send it

The trigger is an explicit /persona-outreach request with a named buyer persona. The persona outreach researcher sources candidates, checks identity and fit, reads prior context, and prepares a draft action. Customer matching and Factory exclusion rules sit ahead of scoring. A high fit or Sales Heat Index, abbreviated as SHI, never overrides an exclusion.

Approved inputs include the persona definition, public creator evidence, prospect tags, discovery context, recent articles, customer identity records, and prior LinkedIn activity. Exact email matching can proceed with high confidence. Fuzzy names wait for verification. Private or surprising research stays out of the message.

The run works in this order:

1. Source candidates from the allowed warm, database, and public discovery lanes.
2. Check whether each candidate already belongs to another active pipeline.
3. Apply the complete Factory exclusion across tags, source, discovery context, notes, activity, and Gmail history. Any Factory creator or partnership signal removes the candidate from this customer-revenue workflow.
4. Verify identity. Ambiguous and fuzzy matches wait for review.
5. Confirm a recent, specific public artifact for candidates who require article-based research.
6. Calculate fit and SHI under the stored rubric, then read the existing message thread before drafting.
7. Create an executive_actions item with status: pending and approval_mode: human_required.

Sanitized example schema, illustrative only:

candidate_state: qualified_for_review
identity_match: exact_email
fit_band: passes_configured_threshold
shi_band: low
exclusions_checked:
  - factory_pipeline
  - active_pipeline
  - customer_identity
research_provenance: public_artifact_verified
action:
  type: linkedin_dm
  status: pending
  approval_mode: human_required
  sent: false

The verifier checks the persona evidence, entity match, exclusions, article takeaway, fit threshold, thread read, and draft voice. Missing article evidence becomes research_pending_article. An ambiguous identity remains manual review. A Factory signal records exclusion and ends the run for this pipeline, even when every other signal looks attractive.

When explicitly invoked, the skill may enrich the bounded research record and write a pending executive action. It may not contact the person, bypass human_required, reuse a prospect from another pipeline, enrich sensitive personal data, or treat a queued draft as a sent message. Research quality determines whether an action can be reviewed. It never grants transport authority.

6. Project-status synthesis: preserve the state transitions

The trigger may be a morning overview, a short daily update, or a request for the next ready task. The current Codex chief-of-staff role coordinates /overview, /daily-update, and /next-task. GitHub Issues remain the source of truth for active work, backlog, blockers, and execution ownership. Repository activity and receipts provide evidence about what happened after planning.

Approved inputs include current GitHub Issues, acceptance criteria, repository activity, active configuration, validation results, deployment checks, and incident or automation receipts. Old plans and reports can supply history, but cannot create active work.

The run keeps four states separate:

1. Planned: an issue or approved brief defines the intended work.
2. Changed: a working-tree diff, commit, or pull request shows implementation activity.
3. Verified: named type, test, build, browser, or incident checks passed against the change.
4. Shipped: deployment and live substance checks show the result reached its destination.

/overview collects the wider context. /daily-update selects first moves, recent changes, blockers, brain health, and one “what to trust less” note. /next-task ranks current issues, excludes blocked or human-decision work by default, then audits the winner's scope, dependencies, and verification commands.

Sanitized example schema, illustrative only:

work_item: issue_number_redacted
planned:
  evidence: open_issue_with_acceptance_criteria
changed:
  evidence: repository_change_seen
verified:
  evidence: validation_receipt_present
shipped:
  evidence: deployment_and_live_check_missing
current_state: verified_not_shipped
trust_note: do_not_infer_release_from_commit

The deterministic verifier rereads the live issue and the receipts cited for each state. A commit cannot prove a deployment. A deployment status cannot prove the page has substantive content. A closed issue without the required receipt triggers investigation instead of a success claim. Missing context, blocked labels, incidents, or conflicting state go back to the issue owner.

This workflow may read, rank, and recommend. It may prepare a bounded handoff for implementation. It may not close issues, invent task state, reprioritize protected work, or report “shipped” from a plan or code change alone. Teams that want several agents to share this evidence need common permissions and current source ownership. The company Second Brain for AI agent teams explores that shared layer.

7. Recurring operating review: evidence before email

The daily trigger belongs to /holding-ceo-daily-email. The weekly trigger belongs to /weekly-memo after its reporting window has closed and the relevant search data has passed its revision delay. A-Iwo reads the resulting functional receipts for CEO decisions, while protected actions still require Iwo.

Daily inputs include the reporting contract, metric dictionary, newest valid receipts, direct source snapshots, current GitHub Issues, and one exact Europe/Warsaw window. Each source receives a class: direct, receipt, adjacent_monitor, or diagnostic. A monitor cannot establish a CEO fact without independent validation.

The daily run is explicit:

1. Read the current contracts and define the reporting window once.
2. Collect PII-free aggregates from approved sources and keep different cohorts separate.
3. Write evidence.json before composing visible copy.
4. Run the integrity gate against a skeletal email.html, then compose the final single-column report.
5. Run the evidence gate, source-index check, Iwo Voice validator, desktop render, and mobile render after every change.
6. If sources disagree, record SOURCE_CONFLICT, mark the conclusion withheld, and link the repair owner.
7. Send exactly once only after explicit authorization. Read the Gmail MIME copy back and append the message identity, read time, window check, source-index check, and action check to the evidence artifact.

The weekly memo resolves one closed window, runs named readouts, labels every figure with its lens and dates, records exclusions, then runs a memo linter. Sources that disagree stay separate rather than being averaged.

/weekly-trust-review adds a different operating artifact: a report about what the system should trust less. The August 21, 2026 review found 174 old plan files and 50 open GitHub Issues. It classified the learning loop as collecting_more_than_improving. Those were dated observations, not a permanent health score. Their value was the action they enabled: keep GitHub as task truth, treat old plans as cleanup candidates, and require generated work to become a decision, issue, test, or product change before calling it learning.

Sanitized example schema, illustrative only:

checked_at: redacted_timestamp
artifacts:
  - evidence.json
  - email.html
sources:
  - evidence_class: direct
    freshness: current
  - evidence_class: diagnostic
    freshness: current
claims:
  - truth_class: withheld
    status: SOURCE_CONFLICT
    repair_owner: linked_issue
send_authorized: false
gmail_readback: null

The deterministic report validator rejects missing source references, mixed windows, stale evidence promoted as fact, unsupported conversion claims, unowned actions, PII-shaped values, and absent readback after an authorized send. The recorded failure can be SOURCE_CONFLICT, BASELINE_REQUIRED, or a withheld claim with a named repair path.

Before a material choice, A-Iwo returns options including doing nothing, a recommendation with trade-off, confidence, missing proof, owner, review date, and stop condition. External sends, publishing, pricing, spend, production-data changes, credentials, legal or reputational choices, people decisions, and recurring automation changes remain protected. This separation lets the review run automatically while keeping authority with Iwo. The Second Brain for AI agents explains how durable context, permissions, and history support recurring runs.

A three-level permission ladder

These examples suggest a practical order for adding autonomy.

Level 1: Read and compose

The agent reads approved sources and produces an artifact. It can draft a brief, email, QA report, decision candidate, or status note. It cannot write to an operating system or affect anyone outside the run. This level gives you failure evidence at low risk.

Level 2: Write bounded internal state

The agent may upsert an idempotent meeting row, add a verified research field, or queue an action as pending and human_required. Every write needs a narrow schema, a stable identity key, a receipt, and a recovery rule. The agent still stops before communication, publication, money, sensitive changes, or a final decision.

Level 3: Execute a protected action

A protected action needs explicit authority tied to the exact artifact and current state. Sending an email requires recipient, thread, body, permission, and post-send readback checks. Publishing requires the approved content hash, current canonical state, and live verification. Pricing, spend, credentials, legal exposure, people decisions, and recurring automation changes stay with Iwo unless a narrow standing charter explicitly covers the action and all its guards pass.

Move upward one side effect at a time. Give each new permission its own verifier, receipt, failure state, and way to revoke authority. The useful question is not “How autonomous is the agent?” Ask, “Which exact consequence can this evidence justify?”

My bet is that assembling agents will keep getting easier. The scarce capability will be knowing which evidence can justify which consequence, then encoding that judgment in a contract another person can audit.

FAQ about AI agent examples

What is a real AI agent example?

A real example names the trigger, role, skills, sources, artifact, verifier, failure state, escalation point, and side effects. It also shows where the workflow stops. A transcript summary becomes an agent workflow when identity, persistence, review, and decision authority are part of the design.

What is the difference between an AI agent and an agent skill?

The agent owns a bounded job and chooses among permitted steps. A skill supplies the repeatable procedure for one task. One agent can invoke several skills, while the same skill can support more than one suitable role. Permissions belong to the workflow contract, not to the name of either component.

Does every AI agent need human approval?

Read-only work can often finish after deterministic checks pass. Bounded internal writes need identity, idempotency, and recovery controls. Human approval belongs at judgment points and before external communication, publication, sensitive data changes, money, or another hard-to-reverse consequence.

Is a high evaluation score enough to approve an artifact?

No. A score reports performance against a rubric. Approval binds a person to an exact artifact and its consequences. This article's first draft scored 81 and still remained unapproved because it was too general. The rewrite changes the content hash, so it needs a fresh evaluation and a new approval decision.

Where should an agent store its memory?

Store source facts in the system that owns them, then persist the workflow artifact and its receipt. A meeting transcript, official decision, GitHub Issue, Gmail thread, and report manifest serve different purposes. Combining them into one undifferentiated memory makes provenance and deletion harder.

Can one agent run all seven workflows?

One coordinating role can route several workflows, but each path still needs separate sources, gates, and permissions. Smaller contracts make failure easier to trace. You’ll Have an AI Agent This Year gives a broader view of these roles at work.

Build one reviewable operating workflow

Pick a recurring job that already ends in a document someone reviews. Write down its trigger, approved sources, artifact, verifier, failure state, escalation point, and prohibited side effects. Start at permission level one. Run realistic failure cases before adding an internal write or external action.

The AI Chief of Staff resource gives you a practical starting structure for meetings, metrics, decisions, and follow-ups. Use it to design one source-backed workflow, then add autonomy only where a gate and receipt can carry the consequence.

Which recurring job could you run at permission level one this week, and what receipt would convince you to allow one reversible internal write?