An agent skill that carries an embedded technical engagement from a vague stakeholder need to an adopted, measured outcome — and stops the engagement when the evidence or authority isn't there.
Get the skill: forward-deployed-engineering in the agent-skills
repository
(SKILL.md, manifest, 8 references, 10 templates, 15 eval cases; optimized in
PR #294).
This demo shows the skill in action using real output from held-out validation runs (synthetic scenarios, no real customers or deployments), then shows what three optimization epochs changed.
Someone embeds a technical lead with a customer or internal team. The request is vague. The sponsor wants it "done." The prototype looks great. And then:
- discovery never reaches the builders,
- a prototype gets called production,
- deployment is declared complete with nobody using it,
- a field pattern gets promoted to a "product" on enthusiasm alone.
The skill is a continuity layer: one accountable lead, one charter, one ledger, and a nine-stage lifecycle with hard gates — while routing specialist work to ~20 existing catalog skills instead of duplicating them.
It is an operating model, not a claim about an industry standard. The nine-stage sequence is the skill's normative design, synthesized from employer-authored role accounts and routed specialist methods.
You ask: "Our operations director keeps describing a problem differently each week. We want to embed one of our technical people with the customer to own this from the vague idea all the way through deployment, adoption, and proving it actually helped. What do we do?"
The skill-guided agent answers (verbatim):
Use the forward-deployed-engineering bundle. This is an embedded engagement requiring one accountable technical lead to preserve continuity from ambiguity through deployment, adoption, measurement, and generalization.
First concrete action: appoint that lead and begin discovery in the customer's actual operating workflow. Meet the operations director, intended users, and decision authority; observe how the work is performed; and record the changing descriptions as observations and unknowns — not requirements.
First required artifact before any solution design: an engagement charter, agreed with the sponsor and decision authority. It must establish: users, workflow, and problem statement; desired outcome and baseline; scope and exclusions; authority and decision rights; constraints and access boundaries; success measure and decision rule; stop conditions and open unknowns.
Do not proceed to solution design until the charter provides a stable, evidence-backed frame. If the problem, authority, constraints, or intended outcome still cannot be named, stop and escalate rather than guessing.
The charter-first rule is a hard gate: no architecture before the problem, authority, and success measure are named.
You ask: "I'm joining an engagement where the charter, workflow map, and an approved requirement already exist, and a thin slice is already in progress. Where do I enter the lifecycle?"
The skill-guided agent answers (verbatim):
You enter at Build, because the requirement has been approved and the thin slice is already underway. Do not restart discovery or re-derive prior decisions.
Review first — establish continuity by reviewing:
- the current engagement charter: scope, outcome, authority, constraints, success measure, stop conditions, recovery boundary;
- the current stakeholder/workflow map;
- the shared assumptions, decisions, and risks ledger, including the evidence and authorized decision approving the requirement;
- the preceding stage-handoff record;
- the current thin-slice implementation plan.
Next three stages:
- Evaluate — required artifact: Evaluation and Release Decision (baseline and thresholds, representative and adversarial evidence, residual risks, rollout/rollback prerequisites, authorized approve/conditional/reject decision);
- Deploy — readiness, rollout, rollback, and verification record;
- Adopt — adoption scorecard and intervention record.
Mid-stream joins are the norm in embedded work. The skill answers "where do I enter?" explicitly instead of making the agent infer it — this was one of the optimization improvements (see below).
You ask: "An LLM workflow demo looked excellent on five hand-picked examples. The sponsor wants it declared production-ready for a high-impact workflow today."
The skill-guided agent answers (verbatim, structured on the skill's release-decision template):
Release Recommendation
- Capability / version / environment: LLM workflow demo; version and target production environment not specified.
- Evaluation owner: Not assigned.
- Decision authority: Authorized business owner for the high-impact workflow.
- Baseline and decision thresholds: Not defined or evidenced.
- Representative evidence: Five hand-picked examples performed well. Engagement observation: this demonstrates promise, but not performance across the target workflow's representative distribution.
- Adversarial or misuse evidence: Not evidenced.
- Operational and trajectory evidence: Not evidenced.
- Known constraints and residual risks: Unknown failure rate and severity; selection bias; untested edge cases; no demonstrated monitoring, recovery, or accountable residual-risk owner.
- Rollout / rollback prerequisites: Not evidenced.
Release decision: Reject today's production release. ... Sponsor enthusiasm and urgency do not substitute for release evidence or decision authority.
Demo ≠ production. The gate requires representative + adversarial evidence, a residual-risk owner, rollout/rollback evidence, and an explicit authorized decision — routed to the evaluation and readiness specialists.
Four requests, one inbox. The skill routes each to the correct owner (verbatim):
| Request | Routed to |
|---|---|
| (A) Vague customer need, embedded lead, adoption + proof required | Forward-deployed-engineering — owns the continuity engagement |
| (B) Checkout API throws intermittently, failing integration test, known stack trace | neckbeard — bounded software change through verified repair and release |
| (C) Which product bets to fund next year + review cadence | product-lifecycle — portfolio and investment governance |
| (D) New SRE hire: SLOs, alert tuning, incident response | site-reliability-engineering — standing operational ownership, not an engagement |
One discipline fully owns a task? Route directly to that specialist. Advisory analysis that ends before implementation? Bypass this skill entirely.
This skill went through a 3-epoch SkillOpt run (controlled, validation-gated optimization: rollouts -> reflection -> bounded edits -> held-out validation -> merge). All-pass baselines throughout, so every edit was judged by regression plus manual verification of the exact diff — 18/18 held-out validation runs passed, 0 regressions.
| Epoch | Before | After |
|---|---|---|
| 1 — prominence | Nine-stage contract lived one reference-load away; the applied-AI gate said "load the evaluation specialist" without naming it | Stage table (required question / minimum output / stop condition) inlined in SKILL.md with template links; release gate names agent-evals-and-observability and production-readiness |
| 2 — decision guidance | Entry point inferred by the model from stage definitions; routing was a flat "do not use for X" list | "Where to enter the lifecycle" table (existing state -> entry stage); proactive Scenario | Reach for | Why routing table. Measurable change: mid-stream workers now echo the entry rule verbatim |
| 3 — pattern expansion | Templates defined structure but nothing calibrated depth | references/worked-example-engagement.md: a fully synthetic completed engagement showing the expected depth — evidence labels, decision-rule application, uncertainty, classification discipline |
The measurable before/after (Epoch 2): before the entry-points table, the agent derived "enter at Build" from stage definitions; after it, the agent echoes the skill's rule ("Do not restart Discover, Frame, or Hypothesize unless the charter's stop conditions require it"). The decision moved from model inference into the skill itself — which is what makes it reproducible across models and harnesses.
- The validation scenarios and responses above are synthetic and generic — no real customer, system, or deployment appears anywhere.
- The skill routes specialist methods; it does not replace them. It has no API keys or network dependencies.
- A stopped engagement is a valid outcome. The skill's stop rules fire when the problem can't be articulated, authority is missing, evidence fails, or adoption stays unexplained — and "stop and preserve the ledger" is the correct move, not a failure.
Published in the agent-skills repository:
bundles/forward-deployed-engineering/
(README, SKILL.md, manifest, 8 references, 10 templates, 15 eval cases).
Optimization: PR #294,
merged with CI green.