1. The thesis
Walk into most companies pursuing AI and you'll find a graveyard of impressive prototypes. A demo that wowed leadership. A pilot that worked beautifully on a clean dataset. A proof-of-concept that never shipped. The explanation everyone reaches for — the model isn't good enough — is almost always wrong. Frontier models are extraordinarily capable. The bottleneck is somewhere else.
The bottleneck is delivery, not modeling. Getting AI into production is a systems problem. The prototype that impressed everyone has to survive real data (messier, larger, more sensitive than the demo set), real integration (with the tools your team already uses), real security review (which a prototype was never designed to pass), and real ownership (by a team that can run and improve it after launch). Each of these is where pilots die — not because the AI was wrong, but because nobody owned the path from "it works in a notebook" to "it runs in production, safely, and our team can maintain it."
This brief lays out how I think about that gap, and the operating model I built ArcusForward to close it. Three sections cover the conditions that make AI delivery possible at all (§2), the embedded operating model itself (§3–§5), and the practical mechanics — security, ownership, engagement structure, federal posture, and how to engage us (§6–§10).
If you only have time for one page, here it is: the work that lives between a prototype and a production system is large, mostly non-modeling, and decides whether the investment pays off. Closing it requires alignment before scope, embedded accountability during the build, and capability transfer — not artifact transfer — at the exit.
2. The five preconditions for production delivery
The most consistent pattern I see is this: when an AI initiative stalls, the failure was almost always present at kickoff. We tell ourselves a stall is a technical surprise. It rarely is. It's an unmet precondition that was always going to surface, and a build that started before those preconditions were honest.
I treat five as non-negotiable before any code is written. Notice how few of them are engineering.
A bounded, high-value problem. Not "do something with AI." A specific outcome someone in the business actually cares about, with a defined cost of inaction. If we can't write the problem in one honest sentence, we won't build a solution that's any clearer.
An executive sponsor with authority. Authority to clear blockers, approve scope, sign off on security exceptions, and decide what "good enough" looks like. Without this, the engagement runs on goodwill — and goodwill collapses under the first hard trade-off.
A named internal owner for after we leave. The person whose job description, after handoff, includes running and improving this system. They have to exist, by name, on day one. If they don't — or if the answer is "we'll figure that out later" — we're shipping a system into an organizational vacuum and the vacuum wins.
A measurable success metric, agreed before scope. What does success look like as a number, against what baseline, decided by whom? "Better than today" is not a metric. Anchoring the engagement to a defined outcome is the only thing that lets us know if we built the right thing or just shipped something.
Alignment readiness. This is the one most teams underestimate, and the one a credentialed peer recently pushed on me directly. Embedding an engineer doesn't substitute for executive sponsorship, a named owner, or — critically — a team that's willing to redesign the workflow the AI is going to sit inside. If the people whose work the system will change aren't part of the conversation before we scope, the engagement will produce software the org can't absorb. That's not a build problem we can engineer our way out of. It's a precondition.
If any of the five aren't real, I say so. The first deliverable in every engagement isn't code — it's an honest read on whether the engagement can succeed at all. Sometimes the most valuable thing we do is decline.
3. The forward deployed model
The standard options for closing an AI delivery gap don't close it.
Consulting delivers a strategy and a deck. It tells you what to do without putting an accountable engineer on doing it. The deck arrives. The system doesn't.
Staffing firms deliver a contractor with hands on a keyboard but no accountability for the outcome — and no obligation to leave the team stronger.
Hiring is the right long-term answer, but senior engineering talent — especially AI-fluent — is scarce, expensive, and slow to recruit. Most enterprises lose two quarters before anyone writes code.
The model elite product companies use internally for problems like this is the forward deployed engineer — a senior engineer who embeds with the customer (often a department, sometimes a single team), is accountable for the outcome, and transfers the capability before they leave. I took that model out of the product-company playbook and built a service around it.
Three properties make it work:
- Proximity. The engineer works inside your environment, on the real problem, with the real constraints. They sit in your standups, push to your repos, and pair with your team.
- Accountability. They own the result through to production, gated by milestones you sign off on. Not billed by the hour.
- Continuity. Knowledge transfer is part of the deliverable, not an afterthought. When they leave, your team owns the system.
The model only works wrapped in a delivery framework with explicit criteria and gates — otherwise it's just an expensive contractor in a sweater. That framework is the next three sections.
4. The delivery framework
Every engagement runs through six gated phases. The client signs off at the gate before the next phase begins. The gate criteria below are the headline; the detailed gate checklists are the work.
| Phase | What happens | Gate |
|---|---|---|
| 00 · Discovery & Fit | Confirm the five preconditions. Define the problem, success metric, and security constraints. Produce a scoped Statement of Work. | Engagement Charter signed |
| 01 · Embed & Architect | Engineer embeds: access, onboarding, environment, standups. Technical discovery. Architecture and evaluation strategy. Risk, compliance, and security plan. | Architecture, delivery plan, and security plan approved |
| 02 · Build | Working software delivered every sprint. Demos and acceptance against explicit acceptance criteria. Evaluation harness on every increment. Continuous documentation. | Each increment accepted against its acceptance checklist |
| 03 · Harden & Secure | Security review and threat-model validation. Compliance validation. Load, failure, and AI-evaluation testing. Runbooks, rollback plan, monitoring. | Production-Readiness Checklist passed and signed |
| 04 · Deploy & Hand Off | Production deployment with monitoring and alerting. Documentation, ADRs, runbooks delivered. Knowledge-transfer sessions and pairing. Ownership transfer of code, infrastructure, and IP. | Project Completion Checklist signed |
| 05 · Stabilize & Exit | Post-launch support window. Metric validation against the success criteria. Transition or follow-on engagement. | Clean exit, or a new charter |
A few things to notice. The first phase ends before any meaningful code is written; if discovery doesn't produce a signed Engagement Charter, we don't proceed. The Build phase is iterative, not waterfall — increments are accepted one at a time against criteria written down before the increment starts. And nothing reaches production until a Production-Readiness Checklist is passed and signed. Passed, not prepared.
The framework isn't novel because gated delivery is novel — it's been around for decades. It's the willingness to actually walk away at a gate that's the work. The checklist is the easy part to write down. Knowing which item matters most for this engagement, and what "good enough" means in this client's context, is the judgment an embedded engineer brings. That judgment doesn't fit on a page.
5. Capability transfer, not cargo cult
The hardest single problem in this kind of work isn't shipping the system. It's making sure the team that inherits it understands the decisions underneath it well enough to extend it. A peer founder put it sharply in a public exchange a few days before I wrote this brief: teams inherit a system without owning the mental model underneath. Knowledge transfer only sticks when engineers teach decision-making, not just hand off code. That's the difference between capability transfer and cargo cult engineering.
He's right, and it's the failure mode I design every engagement against from week one. Three practices:
Architecture Decision Records. Every meaningful technical decision is captured in a short written record — the option chosen, the alternatives considered, the trade-offs, the constraints. ADRs aren't documentation theater. They're the why the next engineer needs in three months when the world has changed. Code without the why is a maintenance hostage.
Paired build, not handoff training. The client's engineers don't show up at the end of the engagement to be handed a finished system. They pair through the build — design discussions, code review, deployment, evaluation harness. By exit they've already touched every part of the system, in context, with the decisions being made. That's how mental models actually form.
The reverse-shadow week. Before exit, the client's team drives — they do the deploys, run the evals, handle the changes — while we shadow and answer questions. If they can't, the engagement isn't over. The handover bar isn't we delivered the code. It's the owning team can change, deploy, and roll back unassisted.
We call this exit by design. The whole engagement is structured backward from a successful exit. Every artifact, every session, every pairing decision is in service of that outcome. The opposite — a successful build that leaves the team unable to maintain it — is the cargo-cult failure: all of the structure, none of the understanding.
6. Security and compliance as phase gates
The fastest way to kill a promising AI project is to defer security to the end. It is also the most common way. The pattern is predictable: build the thing, demo the thing, send the thing to a security review it was never designed to pass — and now you're retrofitting controls into an architecture that assumed none.
For AI systems specifically, that retrofit is the most expensive imaginable point to discover that you have a prompt-injection surface, an over-privileged service account, or a data path that violates your own retention policy. So in our framework, security and compliance enter at two points before anything ships:
- Discovery captures the regulatory and contractual obligations the solution must live inside.
- Architecture produces a threat model and a compliance plan mapped to those obligations.
By the time we reach Harden & Secure, that phase is a validation of decisions already made, not a scramble to add controls a demo never had. Six categories gate the production launch:
| Gate | What's validated |
|---|---|
| Security review | Findings remediated or accepted in writing |
| Compliance validation | Against agreed frameworks |
| Observability & audit | Logging, metrics, alerting, audit trail |
| Eval-gated release | Quality regressions cannot reach production silently |
| Rollback tested | Incident response runbook actually exercised |
| Data handling | Classification, retention, PII paths validated |
Frameworks we design around — adapted to whichever the client actually carries — include SOC 2, HIPAA, GDPR/CCPA, ISO 27001 / NIST alignment, NIST SP 800-171 / CMMC for federal / DoD CUI environments, and FedRAMP-style baselines where applicable. We design around the client's existing compliance posture; we do not impose a framework on you.
For AI specifically, the gate is more than generic application security. Input and output validation around model calls, prompt-injection mitigation, guardrails and policy enforcement on what models are allowed to do, human-in-the-loop for high-risk or irreversible operations, eval-gated releases so a quality regression cannot ship silently, explicit data handling — what's allowed to leave the environment, what can or can't be sent to model providers, retention. None of this is a separate "AI security workstream." It's the same gate, with AI-aware criteria.
A team that treats security as a phase gate ships slower in week one and far faster in month three — because nothing has to be rebuilt after review.
7. Ownership and exit by design
The single most-stated promise in the consulting world is "no lock-in." It almost never means what the buyer thinks it means. Most of the time it means we'll give you the code if you ask. That's not ownership. That's a deliverable.
Real ownership transfer means everything the team needs to run and change the system independently moves to them. Specifically:
- Source code in client-owned repositories.
- Infrastructure-as-code transferred; the infrastructure itself in client-owned cloud accounts. (We don't host your production system in our accounts. Strongly recommended pattern, occasionally a contracted exception.)
- Secrets and credentials rotated to client control. Our access revoked.
- Documentation, architecture decision records, and runbooks delivered and stored in client-owned locations.
- Evaluation suites and the data behind them — the things that let the client's team validate quality after we leave.
- Knowledge transfer artifacts: session recordings, pairing notes, the reverse-shadow week's runbooks.
- IP per the engagement agreement — typically client-owned for engagement-specific work.
Then we leave. Optionally a short stabilization window — a contracted post-launch support period, scoped explicitly — but that's an option, not a default. Default is clean exit.
What I will not do is sell a system that requires us to keep operating it. That's a recurring-revenue model dressed up as a service. It's a fine business — for someone else.
8. Engagement models
Three shapes the engagement can take.
Sprint (a few weeks). Validate a single high-value use case and prove a path to production. Discovery and fit, one embedded engineer, working prototype plus a go / no-go recommendation. Useful when the underlying question is whether to invest at all.
Embedded Build (multi-month, the common shape). Take a prioritized use case all the way to a deployed, owned production system. Full engagement framework, embedded engineer in your team, production deployment plus knowledge transfer. This is the engagement most clients need.
Ongoing Forward Deployed Engineer (rolling). A standing FDE driving a portfolio of AI initiatives. Dedicated senior engineer, quarterly roadmap and reviews, continuous delivery and enablement. The right shape when AI is becoming a portfolio capability rather than a project.
Pricing posture. Scoped case by case during discovery — against the problem and the outcome, never open-ended hourly work. You pay for results against agreed milestones, not for time on a clock. Open-ended hourly billing makes scope creep the contractor's incentive. Outcome-gated milestones make production the contractor's incentive. I prefer the second.
9. Federal and SDVOSB readiness
ArcusForward is a division of Arcus Forge LLC, a verified Service-Disabled Veteran-Owned Small Business (SDVOSB). For federal pursuits, this matters in specific, practical ways:
- Set-aside eligibility for SDVOSB and small business contract vehicles.
- Familiarity with FAR / DFARS flow-downs, prime-versus-sub posture, and the realities of federal contracting operations.
- Security baseline awareness — NIST SP 800-171, CMMC level expectations, FedRAMP impact levels, DoD IL boundaries, and the question federal program managers actually care about: who owns the ATO. We engineer around the client's ATO boundary; we don't try to inherit or replace it.
- CUI-aware design by default where engagements involve Controlled Unclassified Information. ITAR/EAR-controlled environments scoped per engagement.
- SAM.gov-registered, with the standard reps & certs federal contracting officers expect.
For federal engagements specifically: scope, security baseline, and ATO ownership are confirmed in discovery. We don't commit a delivery date until the contracting vehicle and the security boundary are real.
10. About Arcus Forge LLC, and how to engage
ArcusForward is the forward deployed engineering practice of Arcus Forge LLC, a Florida-based SDVOSB founded in 2025 by Zachary Meyer (Co-Founder & CEO, Service-Disabled Veteran, DevSecOps and federal compliance background) and Kenneth Starling (Co-Founder & Technical Lead, senior systems analyst across financial services, healthcare, and maritime logistics; specializes in compliance, security architecture, and federal contracting operations).
The first conversation is short and free: a thirty-minute discovery call. The point of that call isn't to sell you on an engagement. The point is to pressure-test your use case against the five preconditions, outline an honest path to production, and tell you whether — and how — an embedded engagement gets you there. If it doesn't, I'll say so.
Book at arcusforward.com or write directly to sales@arcusforge.com.
The checklist is the easy part to write down. The judgment behind it is the work.
© 2026 Arcus Forge LLC. All rights reserved. ArcusForward is a division of Arcus Forge LLC, a verified Service-Disabled Veteran-Owned Small Business (SDVOSB).