Agentic Engineering

Refactor a skill or workflow so the model can execute more work with less human steering, while preserving verification, provenance, security, and the professional quality ceiling.

Agentic Engineering is the step after vibe coding: speed is useful only if quality does not degrade. Humans keep ownership of taste, judgment, architecture, and risk boundaries; agents execute bounded macro actions with evidence.

Agent Understanding Model

Use the Karpathy-style LLM OS mapping as the design baseline:

The agent is a process with state, tools, permissions, and write-back duties. Do not design skills as advice pages; design them as executable control loops.

Full-Stack Agent Pattern

Use the Google I/O '26 wiki update as the new maturity signal: useful agents are moving from chat boxes into full-stack product surfaces.

Do not treat these as separate prompt styles. They are one full-stack agent design problem: model -> context -> tool calls -> product surface -> verification -> governance.

Workflow Complexity Gate

Before adding orchestration, classify the work at the lowest sufficient level:

Default to the lower level when value, independence, or verification is unclear. Higher orchestration increases token cost, permission surface, and audit burden.

Usage Template

Prompt

Use agentic-engineering to revise this skill/workflow. Make it model-native, concise, autonomous, verifiable, and long-horizon capable.

Use Case

• Improving an existing skill, SOP, command, agent workflow, or multi-agent plan.

Expected Result

• A compact agentic workflow with clear defaults, state checkpoints, verification gates, and escalation rules.

Output Example

• A revised SKILL.md with model assumptions, autonomous execution loop, quality gates, and anti-patterns.

Verification Case

• A fresh agent can run the workflow without repeated clarification and can prove completion with evidence.

Verified Effect

• Human coordination load drops; the LLM spends fewer tokens asking for obvious decisions and more tokens executing, checking, and learning.

Success Metrics

• Revised workflow has one trigger, one bounded macro action, one state checkpoint, one verification gate, and one write-back target.
• The skill or workflow can be executed without extra clarification for its primary use case.
• Residual human judgment points are explicit rather than hidden in vague prose.

Model Meta-Properties

Design around the model as it is, not as a human assistant metaphor.

Workflow

1. Define the Quality Ceiling

Name the standard that must not drop:

Quality ceiling:
User-visible risk:
Security risk:
Verification evidence:
Human judgment required:

If quality cannot be measured or inspected, do not delegate broad autonomous work yet.

2. Compress the Contract

State the workflow in one sentence:

Input -> transformation -> durable output -> verification evidence

If this sentence is vague, fix it before adding steps.

3. Write the Macro Action Spec

Before assigning a large unit of work, define:

Objective:
Scope:
Non-goals:
Inputs:
Owned files or territory:
Expected output:
Verification evidence:
Security/risk review:
Write-back destination:
Stop condition:

Treat features, research, plans, and verification as macro actions. Shrink the action until ownership and proof are clear.

For delegated actions that can affect a user, account, purchase, external system, public claim, or generated media artifact, add:

User mandate:
Authority boundary:
Budget/cost limit:
Reversibility:
Audit/provenance record:
User confirmation point:

4. Set Autonomy Defaults

Use this escalation policy:

5. Externalize State

For long tasks, create or update one durable state artifact:

Goal:
Current step:
Assumptions:
Files touched:
Evidence:
Open risks:
Next action:

Avoid relying on chat memory for multi-hour or multi-session continuity.

6. Use the Thin Loop

Boot minimal context.
Plan the next smallest useful step.
Act with tools as system calls.
Observe environmental evidence.
Update durable state.
Verify or iterate.
Write back reusable learning.
Stop when definition of done is proven.

Keep the loop short. Do not produce broad plans unless the task is broad.

7. Add an Evaluator or Red Team When Risk Is High

Use a separate critic, test suite, or adversarial pass when output touches:

• authentication, permissions, secrets, payment, legal, or data deletion
• public-facing claims, launch materials, or user trust
• architecture that is hard to reverse
• generated code without strong tests

For security-sensitive work, the minimum pattern is:

Builder output -> evaluator review -> adversarial test -> fix loop -> final proof

8. Use AutoResearch Only Inside Evaluation Boundaries

Allow long autonomous experimentation only when:

• the metric is objective
• evaluation is cheap and repeatable
• safety, cost, and runtime limits are explicit

Otherwise keep the loop supervised with human review gates.

9. Convert Human Collaboration into Interfaces

Replace repeated human check-ins with artifacts:

10. Verify Before Claiming

Every completion claim needs fresh evidence:

• files exist or diffs show expected edits
• tests, lint, link checks, or schema checks pass
• source references resolve
• known residual risks are named

For vendor-keynote, launch, or product-roadmap claims, mark single-source status until checked against public docs, changelogs, or independent usage evidence.

11. Close the Memory Loop

After significant output, decide where the result belongs:

Quality Gates

• [ ] Trigger description says exactly when to use the skill.
• [ ] SKILL.md removes generic teaching and keeps only non-obvious procedure.
• [ ] Workflow has safe defaults and a narrow ask-user policy.
• [ ] Macro actions have scope, owner, non-goals, proof, and stop condition.
• [ ] Delegated external actions define mandate, authority, cost, reversibility, and audit record.
• [ ] Long-horizon tasks have checkpoints or state artifacts.
• [ ] Workflow complexity is justified at the lowest sufficient level.
• [ ] Quality gates include executable or inspectable evidence.
• [ ] High-risk work has evaluator, critic, or adversarial review.
• [ ] AutoResearch loops have objective metrics, cheap evals, and explicit limits.
• [ ] Significant outputs have a write-back destination.
• [ ] Anti-patterns name the most likely model failure modes.
• [ ] Output format is concrete enough for another agent to follow.

Anti-patterns

• Asking the user to decide routine reversible details.
• Writing long philosophy where a table or checklist would guide better.
• Claiming completion from confidence instead of verification.
• Keeping state only in conversation.
• Treating tools as magic actions instead of permissioned system calls.
• Optimizing for one impressive answer instead of a reusable loop.
• Delegating a large macro action without non-goals, ownership, proof, or a stop condition.
• Letting an agent buy, publish, message, schedule, or mutate external state without an explicit mandate and audit trail.
• Running autonomous iteration where success depends on taste or risk judgment rather than a cheap metric.