Video summary

От задачи до PR: как построить надёжный AI agent workflow | Agentweaver

Main summary

Key takeaways

Technology

Summary (technological concepts & workflow)

The video explains “Agent Harness” / “harness engineering” as an approach for making AI agents reliable enough for real engineering work (e.g., turning Jira tickets into code). It argues that the common method—prompt an LLM → get code back—is unstable because it:

  • loses context,
  • mixes steps,
  • skips checks,
  • produces results that can’t be trusted consistently.

Instead, the agent is embedded into a controlled engineering pipeline with:

  • explicit stages,
  • verification steps,
  • transition rules,
  • feedback/correction loops,
  • clear termination conditions.

Core workflow stages (pipeline)

  1. Input from a real artifact (Jira ticket)

    • Starts from concrete task data (description, requirements, acceptance criteria, comments, etc.), not a vague chat prompt.
    • Goal: preserve context and reduce “retelling” errors.

  2. Context acquisition / “GFEch” step

    • The system takes over the task along with its associated context so the model uses structured ticket data.

  3. Quality gates / guard rails

    • The workflow checks whether it’s even possible to proceed.
    • Examples of failures:
      • empty task,
      • weak description,
      • missing required fields,
      • missing context collection.
    • If gates fail, the process returns for correction (not forward blindly).

  4. Design & planning stage (major emphasis)

    • Instead of writing code immediately, the agent:
      • breaks down the task,
      • identifies affected system parts,
      • chooses implementation order,
      • enumerates risks / edge cases,
      • produces an action plan/design artifacts.
    • Goal: reduce chaos caused by jumping straight from ticket → code.

  5. Checkpoint verification

    • Intermediate planning artifacts must be verified.
    • The system doesn’t accept model output “because it looks plausible.”

  6. Implementation stage

    • The model writes code based on prior design/planning artifacts, not directly from the raw ticket.
    • Emphasis: the model is not “working in a vacuum.”

  7. Linter stage

    • Automated code quality checks (style, obvious errors, rule violations, suspicious areas).
    • On failure: goes to a fix branch with specific feedback, then re-verifies.

  8. Tests stage

    • Validates behavior; even “clean” code must pass tests.
    • On failure: the correction loop runs again with test feedback.

  9. Review loop (critic stage)

    • Adds an extra review stage (often including a human in real systems) that evaluates:
      • whether it meets the task,
      • whether complexity is justified,
      • risks/violations missed by linter/tests,
      • architectural correctness and side effects.
    • Failures trigger another fix cycle.

  10. Re-run checks until gates pass

    • Any change may break something, so linter/tests/reviews are repeated after fixes.

Key “product features” of the harness concept

The video lists harness features such as:

  • Controlled loop: the model can’t freely choose the next step; it must follow the workflow.
  • Clear stages: pipeline is reproducible and observable.
  • Machine-readable artifacts between stages (not just chat history), enabling validation and reuse.
  • Quality assurance at transitions (verification/validation at every major step).
  • Explicit transition rules: the system knows when to proceed vs. revert and correct.
  • Integrated feedback loops: errors/comments are handled naturally, not as after-the-fact fixes.
  • Tool use & orchestration: runs external tools like linters, tests, repositories, task trackers.
  • Observability: visibility into the current stage, pass/fail reasons, and why the workflow returned.
  • Guard rails / quality gates: risk controls preventing uncontrolled progression.

Practical demo described

  • The demo uses:
    • a Go project,
    • a Jira ticket describing medium-complexity changes (API edits + repo changes affecting multiple layers),
    • Agentweaver (an agent orchestration tool developed by the speaker, hosted on GitHub).
  • The pipeline is configured to include linters and tests in the standard flow.
  • During planning, the model may ask clarifying questions; the tool surfaces these as interactive dialogs and stores them as machine-readable artifacts.
  • Notifications are sent (e.g., via Telegram) when:
    • planning completes, and
    • design review finishes.
  • Artifacts produced include:
    • Human-readable MD and machine-readable JSON (“Jon” in subtitles) documents,
    • design documents,
    • implementation plans,
    • a QA quality control plan,
    • review summaries and design review results.
  • The speaker notes an issue during recording:
    • some stages (e.g., linter/test) were accidentally skipped in the demo UI,
    • then they were run manually afterward to confirm correctness.
  • Output:
    • a GitHub pull request becomes ready for merge after the full harness cycle
    • (with the caveat that real usage would proceed to further testing rather than “closing” immediately).

Main speakers / sources

  • M. (the speaker at the end; the video appears to be presented by the creator/developer of Agentweaver)
  • Primary tool mentioned: Agentweaver (agent orchestration on GitHub)

Original video