The FDE Should Leave You Stronger

Forward deployment can solve a real problem.

Enterprise workflows do not arrive as clean API specifications. They contain tacit rules, exceptions, ownership gaps, access boundaries, and language that only makes sense inside the organization. An engineer working alongside the client can turn those conditions into a functioning system faster than a remote product team waiting for perfect requirements.

The same role can create a dependency.

If the Forward Deployed Engineer becomes the permanent translator between the organization and its AI system, implementation has not transferred capability. It has installed a human interface owned by the supplier.

Our FDE objective for BAMS is explicit: make the client less dependent on BlackUnicorn.

BAMS approval and decision evidence. All displayed data is simulated.

The FDE Is Part of the Delivery System

BAMS provides an operating layer for governed enterprise AI. It includes work surfaces, agent identities, approvals, memory, model routing, governance, audit, and control mechanisms.

The product cannot decide the client's operating model by itself.

Someone must map the real workflow into those controls:

• identify the authoritative sources
• define the accountable owner
• translate role language into permissions
• define proposal and action boundaries
• configure model and data routes
• connect named tools
• design approval and exception states
• establish required evidence
• test stop and recovery procedures
• train the client operators

That is the FDE's work.

It is product work because the result determines whether BAMS fits the organization. It is service work because the mapping is specific to the client.

The engagement needs a clear end state so the service does not become a permanent dependency.

Measure Dependency Down

Implementation programs often measure activity: integrations configured, workshops held, agents created, prompts written, or tickets closed.

Those measures do not show whether the client can operate the system.

We prefer a dependency test.

At the beginning of the engagement, BlackUnicorn may perform many routine actions. By handover, client operators should perform them from documented procedures.

The transfer can be tracked across six capabilities:

1. Operate the deployment and inspect health.
2. Change a scoped agent permission.
3. Change or disable an approved model route.
4. Review and resolve an approval or exception.
5. Pause, recover, and decommission a software identity.
6. Export the agreed context and evidence.

The objective is not zero contact. The objective is that normal operation and agreed changes do not require BlackUnicorn to interpret the system for the client.

The FDE Charter

A no-strings-attached engagement needs a written charter. Ours should include the following obligations.

Work on one bounded production workflow

The FDE begins with a specific workflow, owner, source boundary, and acceptance condition. Broad platform enablement is not an acceptance test.

Build in the client's environment

The target deployment runs in infrastructure selected and controlled by the client, subject to the commercial beta architecture and agreed prerequisites.

Use client-owned accounts and credentials

Provider, connector, and operational credentials should be owned through the client's approved process. Supplier credentials should not become hidden production dependencies.

Record every material decision

Architecture choices, access rules, route policies, limitations, exceptions, and accepted risks belong in the operating record.

Teach through the real workflow

Training uses the deployed workflow and its failure states. A generic product tour does not prove operating readiness.

Test the exit before acceptance

Provider disable, agent pause, connector revocation, evidence export, supplier access removal, and handover procedures should be demonstrated and recorded for the agreed scope.

Leave an ownership map

Every routine operation and exception needs a client owner. The document should also name which issues remain BlackUnicorn product support responsibilities.

Handover Is a Test, Not a Folder

A collection of diagrams and runbooks can look complete without being usable.

Handover should require client operators to perform the work.

For example:

• A client administrator provisions or changes a scoped agent identity.
• A risk owner reviews an approval with the required evidence.
• An operator disables a model provider and explains the failure path.
• A knowledge owner corrects or retires a governed memory.
• An infrastructure operator follows the recovery procedure.
• An authorized owner exports the agreed evidence.

The FDE observes, records gaps, updates the procedure, and asks the client operator to repeat the task.

That loop turns documentation into an operating capability.

What the Client Receives

The handover packet for a BAMS lighthouse workflow should include:

Architecture

• deployed components and boundaries
• data flow and classification points
• model and provider routes
• external integration inventory
• storage, backup, and recovery assumptions

Authority

• agent identity registry
• accountable human owners
• access and tool permissions
• budgets and quotas
• approval and escalation matrix

Operations

• health and routine-operation runbooks
• route change and provider disable procedure
• agent pause, recovery, and decommission procedure
• connector failure and credential rotation procedure
• knowledge update, retention, and export procedure

Evidence

• workflow acceptance results
• denied-access and failure-path results
• disconnect drill results
• known limitations and accepted risks
• open productization items

Exit

• client and supplier access inventory
• export contents and format
• credential revocation steps
• continuing-use rights under the agreement
• transition owners

The packet should distinguish product configuration from client policy. That lets the organization change its own rules without treating every change as a product defect.

BAMS Supports the Transfer

The BAMS reference implementation exposes the objects an FDE and client operator need to share.

Projects, milestones, and journals hold the delivery record. Approvals carry decision context. Agent identities make authority visible. Model routing exposes provider choices. Memory surfaces show organizational context. Governance and audit record control activity. Circuit breakers and lifecycle operations provide stop and recovery mechanisms.

The product does not make the FDE objective automatic. It gives the engagement a common operating surface and evidence trail.

That is important because a handover should not depend on the FDE's private notes. Material decisions belong in the system or in client-owned documentation.

Current Product and Service Boundary

BAMS is a working internal reference implementation being productized as a commercial beta appliance for deployment into client-controlled environments.

The FDE charter described here is a proposed BlackUnicorn delivery commitment. Its exact scope, prerequisites, access, acceptance criteria, and continuing support belong in the signed statement of work.

We will not present service intent as product telemetry. We can show the BAMS control surfaces today. We must prove handover by having client operators perform the agreed tasks and recording the result.

The distinction protects both parties. The client knows which capabilities exist in the product and which outcomes the engagement must deliver. BlackUnicorn has a measurable definition of done.

Signs of the Wrong Dependency

An engagement needs correction when:

• only the FDE can explain the routing rules
• production credentials sit in supplier-owned accounts
• permissions are changed through undocumented messages
• failure states require the FDE to interpret raw logs
• runbooks have never been used by a client operator
• the client cannot disable a provider or agent
• evidence export requires a custom supplier intervention
• routine operation stops when the FDE is unavailable

These are not signs that the FDE is valuable. They are signs that transfer is incomplete.

Leave the Organization Stronger

Forward deployment is useful because the last kilometre is real. It is specific, organizational, and difficult to solve through generic configuration alone.

The answer is not to remove the FDE. It is to give the role the right objective.

Deploy the workflow. Make authority explicit. Document the architecture. Test failure and exit. Train the operators. Transfer routine control. Record what remains unfinished.

The FDE comes with BAMS.

The dependency does not have to.

A RACI Is Not the Ownership Map

Traditional delivery documents can list who is responsible, accountable, consulted, and informed while leaving the operational action unclear.

The BAMS handover needs a more concrete map.

For each routine or exception operation, record:

• the action to perform
• the BAMS role permitted to perform it
• the accountable client owner
• the evidence required before the action
• the approval required, if any
• the system state produced by the action
• the recovery or reversal procedure
• the supplier responsibility that remains

For example, "disable an external model provider" is not only an infrastructure task. The owner needs to understand which workflows use the route, which fail closed, which have an approved fallback, which queued work requires review, and who may restore service.

The ownership map connects technical control to business consequence.

Support Without Dependence

No strings attached does not require the client to reject support.

BlackUnicorn can continue to provide product updates, technical support, architecture review, and additional deployment work under an agreed relationship. The boundary is that the client can operate the accepted workflow and exercise its control and exit rights without that support becoming a hidden prerequisite.

This distinction allows a healthy continuing relationship.

The client can choose BlackUnicorn because the support remains valuable, not because the system becomes unintelligible without it.

The support model should therefore state:

1. Which product issues BlackUnicorn owns.
2. Which infrastructure issues the client owns.
3. Which workflow and policy decisions belong to the client.
4. Which response and escalation path applies.
5. Which remote access BlackUnicorn may receive and how it is revoked.
6. Which logs or evidence can be shared without exposing restricted data.
7. Which changes require a new acceptance test.

The handover is stronger when this boundary is explicit.

The Final FDE Review

Before acceptance, the FDE and client owner should review the system from three positions.

Product

Which BAMS capabilities are configured? Which controls are enforced? Which remain advisory? Which commercial beta limitations remain open?

Workflow

Does the bounded process meet its acceptance condition under normal, denied, rejected, failed, paused, and recovered states?

Ownership

Can the client's operators perform routine control, change, evidence, recovery, and exit tasks from the handover material?

A result can pass one position and fail another. The model may produce the right output while the operator cannot recover it. The client may run the workflow while a connector remains insufficiently hardened. The product may expose a control while the engagement has not assigned its owner.

The final review records each dimension separately.

This is how the FDE leaves a useful truth behind: not a declaration that deployment is complete, but an operating system whose current capability, ownership, and limitations are clear to the client.

An FDE Exit Criterion

The engagement needs a simple way to determine when forward deployment has become normal product support.

For the accepted workflow, BlackUnicorn should no longer be required for routine health inspection, approval handling, scoped permission changes, provider disable, agent pause, context correction, evidence export, or the first recovery action.

The client may still choose to involve BlackUnicorn. The distinction is that the action does not depend on private FDE knowledge or supplier-owned credentials.

If one of these operations remains too risky for client control, the final record should explain why, assign continuing responsibility, and state the exit condition. The engagement should not quietly call the gap a support feature.

The same principle applies to custom work. If a deployment-specific procedure becomes necessary, document it in the client-owned operating packet. If the requirement is reusable across deployments, return it to the BAMS product backlog with a clear commercial-beta boundary.

This keeps service and product work connected without confusing them.

The FDE finishes when the client can exercise the agreed operating rights and both parties understand the remaining dependencies. Continued collaboration can then begin from choice rather than operational necessity.

<!-- Editorial evidence: E08 in series/bams-no-strings-attached/EVIDENCE-LEDGER.md -->