One Production Workflow in 30 Days

Enterprise AI programs often start with a platform decision and a long list of possible use cases.

The list creates support. It also makes acceptance difficult.

If the program contains ten departments, twenty integrations, several model providers, and an open-ended goal to improve productivity, no single operator can say when the system has become production-ready.

We prefer a narrower commitment for the first BAMS deployment:

One production workflow. Thirty days. One accountable client owner. One acceptance record. One handover.

The time frame is a proposed delivery plan, not an unconditional guarantee. It depends on a bounded workflow, available client owners, approved access, and named systems. The purpose is to make scope and responsibility visible from the beginning.

BAMS project, milestone, and journal surfaces. All displayed data is simulated.

What Counts as One Workflow

A workflow has a trigger, inputs, state, decisions, outputs, exceptions, and an accountable owner.

"Use AI in procurement" is not one workflow.

"Review each new supplier agreement from the approved repository, produce a clause summary and risk recommendation, route defined exceptions to legal, and record the decision for procurement" can be one workflow.

The second statement gives the team something to map and test.

A suitable lighthouse workflow should have:

• a named business owner
• a clear trigger and completion state
• a limited set of authoritative sources
• a manageable permission boundary
• a repeatable task where model capability is already plausible
• an approval owner for consequential actions
• available examples for testing
• an outcome that operators can verify
• a failure state that can be contained
• enough value to justify production operation

It should not require the organization to redesign a complete department during the first month.

Prerequisites Before Day One

The 30-day clock should not hide preparation that only the client can provide.

Before the engagement starts, BlackUnicorn and the client agree on:

1. The workflow statement and prohibited actions.
2. The accountable executive and operating owner.
3. The source systems and data classification.
4. The people who can approve access, security, and workflow decisions.
5. The target deployment environment.
6. The model providers or local inference paths permitted for evaluation.
7. The integration scope.
8. The sample cases and expected outputs used for acceptance.
9. The client operators who will receive the handover.
10. The conditions that pause the schedule.

If access or ownership is unavailable, the plan should say so. A date does not solve an unresolved authority problem.

Week 1: Map the Work and Bound the System

The first week turns the workflow into an operating specification.

The FDE works with the client owner to document:

• the work object and lifecycle states
• the authoritative inputs
• the required output
• the human decision points
• the agent's permitted and prohibited actions
• the organizational context required
• the model and data-route constraints
• the evidence required for each completed case
• the exception and failure states
• the exit and handover conditions

The BAMS project record holds the objective, owners, milestones, risks, and journal. The identity model begins with a distinct agent purpose and authority envelope. The approval model is designed into the state flow rather than added after automation.

Week 1 ends with a signed workflow map and acceptance cases. It does not end with a generic product demonstration.

Week 1 gate

• workflow owner accepts the bounded scope
• security and data owners accept the source boundary
• prohibited actions are explicit
• acceptance cases are available
• blocked prerequisites have named owners

Week 2: Deploy the Path and Connect Named Sources

The second week establishes the technical path in the target environment.

The team deploys the agreed BAMS commercial beta components, configures identity and access, connects the named sources, defines memory and retrieval scope, configures permitted model routes, and establishes the approval path.

Each connector is treated as an operational component. Its credentials, permissions, health, retry behaviour, and failure state are recorded.

The team does not expand integration scope because an additional system appears useful. New sources enter the backlog unless they are required for the agreed acceptance condition.

This protects the schedule and the data boundary.

Week 2 gate

• target components run in the agreed environment
• agent identity and permissions are visible
• approved sources can be retrieved under access rules
• denied sources remain denied
• model routes and budgets are configured
• approval and evidence paths exist
• connector health and failure state are documented

Week 3: Test the Work, Failure, and Evidence

The third week is not a prompt-tuning sprint. It is an operating test.

The team runs the agreed cases and records whether the workflow produces the required output under the required controls.

The test set includes successful work and failure conditions:

• a normal case
• missing or ambiguous context
• denied access
• a source conflict
• a rejected approval
• a provider or connector failure
• an action outside agent authority
• a budget or quota boundary
• a paused agent
• a case that requires evidence reconstruction

Where model quality fails, the team can adjust instructions, context, route, tool use, or scope. Where operating controls fail, the team changes the workflow or implementation.

The distinction matters. A better model response does not repair a missing permission check.

Week 3 gate

• agreed cases produce recorded results
• prohibited actions remain blocked or escalated
• denied access tests pass
• approval decisions change workflow state correctly
• failure paths are visible to the operator
• required evidence can be reconstructed
• limitations and accepted risks are recorded

Week 4: Operate, Disconnect, and Hand Over

The final week moves control to client operators.

The FDE completes the runbooks and asks the designated operators to perform the routine and failure procedures.

The client should be able to:

1. Inspect workflow and system health.
2. Resolve an approval and an exception.
3. Change a scoped agent permission through the agreed process.
4. Disable a model provider and explain the result.
5. Pause and recover the agent.
6. Inspect and correct governed context.
7. Export the agreed work and evidence record.
8. Revoke supplier access according to the exit procedure.

The team also runs the scoped disconnect drill. The result is measured and recorded. A failed step remains an open acceptance item rather than being described as complete.

Week 4 gate

• client operators complete the agreed runbook tasks
• ownership map covers routine and exception work
• disconnect drill result is recorded
• export contents are verified
• supplier and client access are documented
• known limitations have owners and disposition
• workflow owner signs or rejects acceptance

What Acceptance Means

Acceptance is not that the agent produced a persuasive answer once.

It means the workflow has a durable work object, a bounded software identity, governed context, permitted model routes, explicit approvals, visible failure states, reconstructable evidence, stop controls, documented operations, and a client owner who can run it.

The acceptance record should state what passed, what did not, and what remains outside scope.

This protects the client from a vague success declaration. It also protects the product team from an expanding definition of the first workflow.

What Does Not Fit in Thirty Days

A bounded plan also names what it excludes.

The initial lighthouse is not the place to promise:

• enterprise-wide knowledge integration
• every external connector
• autonomous authority across a department
• complete migration of existing automation
• a universal agent registry for every team
• general-availability packaging
• quantified business outcomes without an agreed baseline

These may become later projects. They should not be smuggled into the first acceptance condition.

The first workflow should create evidence for the next decision: extend, change, pause, or stop.

Current Product Boundary

BAMS has a working internal reference implementation with the work, identity, memory, approval, model, governance, and control surfaces required for this method.

It is being productized as a commercial beta appliance for client-controlled deployment. Repeatable packaging, customer-safe workspace isolation, connector hardening, and buyer evidence exports are part of that work.

The 30-day lighthouse is a proposed engagement structure. It depends on prerequisites and a signed scope. It should not be sold as a fixed timeline regardless of access, complexity, or organizational availability.

The honest commitment is stronger: make the prerequisites explicit, keep the workflow narrow, expose blockers immediately, and accept only what the client can operate.

Start Narrow Enough to Finish

Enterprise ambition does not require a broad first scope.

A production workflow creates a real place to test models, context, authority, evidence, ownership, and exit. It reveals which platform capabilities the organization actually needs. It gives risk owners something concrete to approve. It gives operators something concrete to run.

One workflow in thirty days is not a promise to solve enterprise AI in a month.

It is a disciplined way to stop talking about the platform in the abstract.

Build one governed path. Test it under failure. Hand it to the client. Record the result. Decide what deserves to come next.

Choosing the Lighthouse Workflow

The initial choice deserves care because a poor lighthouse can make a capable system look weak or hide a weak operating design behind an easy task.

We score candidates against six questions.

Is the work repeated often enough to operate?

A rare task may be valuable, but the team will wait too long for real operating evidence. The lighthouse should occur often enough to exercise normal, exception, and recovery paths during the engagement.

Can a human judge the output?

The acceptance owner needs a practical way to distinguish an acceptable result from a plausible one. If the organization cannot define good work, the model cannot resolve that ambiguity for it.

Is the authority boundary clear?

The first workflow should have an explicit point where software stops and a named person decides. A process with unresolved legal or organizational authority will not become clearer through automation.

Are the sources available and governable?

The team needs approved examples, a source owner, and an access path. A workflow that depends on several undocumented repositories is likely to spend the month on data archaeology.

Can failure be contained?

The lighthouse should allow the team to stop, reject, or reverse work without creating an unacceptable business impact. That makes real failure testing possible.

Will the result teach the organization something reusable?

The first workflow should exercise several parts of the operating model: identity, context, routing, approval, evidence, and handover. The goal is one bounded outcome that produces reusable operating knowledge.

The Daily Operating Record

The 30-day structure also requires a visible record of decisions and blockers.

The BAMS project journal can capture the current milestone, owner, decision, evidence, risk, and next action. This prevents the delivery status from fragmenting across meetings and private messages.

At the end of each working day, the team should be able to answer:

• What changed in the workflow or architecture?
• Which acceptance case was run?
• What passed or failed?
• Which client decision is required?
• Which limitation entered the record?
• Has the scope changed?

This is not administrative overhead. It is how a short engagement avoids confusing speed with unrecorded improvisation.

The final acceptance packet should be traceable to these decisions. If a route changed, the reason should be present. If a source was removed, the access or quality finding should be present. If a limitation was accepted, the owner should be present.

Thirty days is short enough that unresolved decisions can consume the complete schedule. The operating record makes that cost visible while there is still time to act.

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