On this page
Learning objectives
- Distinguish an AI feature, an automation, and an owned operating workflow
- Map inputs, decisions, handoffs, exceptions, and feedback for one recurring process
- Set a baseline and a bounded 30-day test with stop conditions
- Assign accountable owners for quality, risk, and workflow operation
Before you start
- • Access to one recurring marketing process and someone who performs it
- • A recent real example of the process, including rejected or revised work
Working definition
AI-native foundations
AI-native marketing is an operating model in which research, decisions, production, distribution, and measurement share structured context and explicit controls. The workflow is the unit of design. A model is one replaceable component inside it. This distinction prevents a polished prompt demo from being mistaken for an improvement to the way work reaches customers.
Most delay sits between tasks: missing evidence, unclear approval, copy-and-paste handoffs, and exceptions with no owner. Speeding up draft generation can simply move the queue downstream.
A workflow map exposes what must remain deterministic, where interpretation is genuinely useful, and which side effects deserve approval. It also supplies the baseline needed to judge whether the change helped.
Versioned inputs, decisions, and reviewer feedback turn operating experience into an asset. Without that record, teams repeat the same prompt experiments and cannot explain why output quality moved.
Risk is easier to govern at a defined boundary. The team can name allowed data, excluded actions, escalation paths, and a manual fallback before real customers or budgets are affected.
Field situation
Northstar Security weekly campaign brief
Named synthetic scenario. Northstar Security is fictional and no performance result is presented as a Tenten or client outcome.
- Owner
- You are the demand generation lead responsible for a weekly campaign brief used by content, paid media, and sales enablement.
- Decision
- Decide whether a bounded research-to-brief workflow should be piloted, where a model may assist, and which decisions remain with named people.
- Starting state
- The brief takes four business days. Notes live across call transcripts, a spreadsheet, chat threads, and a product release document. Writers often wait for missing proof and legal review starts after the first draft.
- Expected outcome
- A one-page charter that another operator can follow, measure, pause, and run manually if the assisted path fails.
Constraints
- • Customer quotes cannot leave the approved workspace
- • Legal must approve externally visible claims
- • The pilot cannot publish, send messages, or change media spend
- • The existing CRM and project board remain systems of record
Worked example
Turning an unbounded copilot idea into a workflow charter
Evidence status: Named synthetic scenarioNorthstar first proposed a general marketing copilot. Process observation showed that drafting was not the main delay. Researchers lacked a shared source ledger, product claims arrived in inconsistent formats, and reviewers could not see what changed. The team selected one weekly brief because its trigger, consumers, inputs, and approval decision were visible.
The pilot extracts approved evidence into a fixed schema, flags missing provenance, and proposes a brief outline. Product marketing confirms positioning, legal approves claims, and the demand lead releases the brief. Publication and spend are excluded. Baseline fields include elapsed time, active labor, revision count, claim corrections, adoption by downstream teams, and run cost. A stop rule pauses the pilot after any untraceable external claim or restricted-data incident.
The worked result is an auditable experiment design, not a performance claim. It clarifies that the first success condition is a complete, source-linked brief accepted by all three consuming teams within the agreed service window. It also shows which evidence would justify expanding scope.
Limits
The company, workflow, and result are synthetic. The example does not estimate ROI, conversion lift, or time savings. Real baselines depend on volume, review burden, integration quality, staff adoption, and the cost of exceptions. NIST guidance informs the risk structure but does not certify this design.
Method
Build it, with checkpoints
Field situation
Decide whether a bounded research-to-brief workflow should be piloted, where a model may assist, and which decisions remain with named people.
- 01Observe one real run
- 02Write an observable outcome
- 03Classify the work
Acceptance checks
A bounded pilot that can be compared with the current process. A new operator should know why the workflow exists, what it may do, when a person decides, how failure is recovered, and what evidence controls the next investment decision.
- 01
Observe one real run
Follow a work item from trigger to consumer. Record the artifact, owner, tool, decision, wait time, rework, and exception at each transition. Do not infer the ideal process from a policy document.
CHECKPOINT · Your map includes at least one normal path, one rejected item, and the person who resolves each exception.
- 02
Write an observable outcome
Name the consumer decision and the service condition the workflow must meet. Establish the present elapsed time, labor, acceptance rate, correction rate, and adoption where data exists. Mark unknowns instead of inventing a baseline.
CHECKPOINT · A reviewer can determine from records whether the target was met without interpreting a slogan such as better content.
- 03
Classify the work
Label each step deterministic, interpretive, human judgment, or external side effect. Reserve model use for work that benefits from language interpretation. Place approval before public claims, customer contact, irreversible writes, and spend.
CHECKPOINT · Every proposed model call has a named input, output contract, reviewer or evaluation, and fallback.
- 04
Set the operating boundary
List allowed systems, data fields, tools, users, and actions. Add explicit exclusions, a run budget, a timeout, a stop rule, and a manual path. Assign the person who can pause the workflow.
CHECKPOINT · The charter answers what happens after a missing input, low-confidence result, tool outage, or restricted-data alert.
- 05
Plan the learning review
Define what each run records and schedule a weekly review. Capture output status, reviewer decision, reason for rejection, elapsed time, active labor, exceptions, estimated cost, and downstream use.
CHECKPOINT · The 30-day review has an owner and written continue, revise, expand, and stop criteria.
Hands-on lab
Write a one-page AI workflow charter
Use Northstar as a pattern, then substitute one recurring workflow from your own team. Keep the first boundary small enough to observe for four weeks.
Prepare
- • Collect one completed work item, one rejected item, and the current checklist
- • Interview the operator and the person who approves the final handoff
- • Confirm which data is restricted and which system is authoritative
Deliverable
A completed charter plus a simple current-state map showing every wait, handoff, approval, side effect, and exception path.
Starter kit: Workflow charter template
Copyable Markdown# Workflow charter
Workflow name:
Business owner:
Operator:
Trigger and frequency:
Consumer and decision supported:
Current baseline: elapsed time / labor / revision / error / adoption
Inputs and systems of record:
Decisions in order:
Deterministic steps:
Model-assisted steps:
Required human approvals:
Excluded actions and data:
Expected output schema:
Success threshold after 30 days:
Stop conditions:
Manual fallback:
Run log owner and review date:Expected result
A bounded pilot that can be compared with the current process. A new operator should know why the workflow exists, what it may do, when a person decides, how failure is recovered, and what evidence controls the next investment decision.
Carry forward
Use the charter as the governing artifact for later research, content, automation, agent, and evaluation modules. Update it when the workflow boundary or approval authority changes.
Acceptance checks
- 01The charter names one recurring trigger, one accountable business owner, and one downstream consumer
- 02At least five baseline fields are present, with unavailable data marked unknown
- 03Every public, customer-facing, budget, or irreversible action has approval or is excluded
- 04Stop conditions and a manual fallback are specific enough to rehearse
- 05The review plan records quality, operating cost, exception load, and adoption separately
What breaks
Failure clinic
F1The pilot produces impressive samples but no one uses them in weekly work.
- Inspect
- Compare the demo prompt with the real trigger, systems, handoffs, and consumer decision.
- Likely cause
- The project began with a tool capability instead of an owned operating problem.
- Repair
- Return to one recurring work item, name its consumer, and rebuild the scope around the actual handoff.
- Prevent next time
- Require a workflow charter and baseline before procurement or model selection.
F2Draft time falls while total cycle time and reviewer frustration rise.
- Inspect
- Measure queues, revision rounds, claim corrections, and active review minutes by stage.
- Likely cause
- Generation was optimized while evidence and approval remained undefined.
- Repair
- Add source fields, acceptance criteria, and review packets before generating more volume.
- Prevent next time
- Measure end-to-end flow and cap work in progress instead of relying on output count.
F3Different operators get incompatible outputs and cannot explain the change.
- Inspect
- Check prompt, model, data snapshot, schema, policy, and reviewer versions for each run.
- Likely cause
- Operating assets were stored in personal chats or edited without change control.
- Repair
- Version the complete run configuration and replay a fixed acceptance set.
- Prevent next time
- Treat prompts, schemas, rubrics, and routing rules as reviewed production assets.
F4A tool outage or malformed result strands live work.
- Inspect
- Trace the last durable state, queued events, partial writes, and ownership of recovery.
- Likely cause
- The happy path was automated without a manual fallback or replay-safe design.
- Repair
- Pause side effects, restore the manual process, reconcile records, and replay only validated items.
- Prevent next time
- Rehearse stop, recovery, and manual operation before increasing volume.
Beyond the demo
Production boundary
- 01Outcome, consumer, baseline, and 30-day decision rule are documented
- 02Input provenance and systems of record are named
- 03Restricted data and prohibited actions are explicit
- 04Human approval sits before material brand, customer, budget, and legal risk
- 05Structured output contracts and validation exist for model-assisted steps
- 06Run logs retain versions, reviewer decisions, cost, and exceptions without excess personal data
- 07A named operator can pause, recover, and run the process manually
- 08Weekly sampling covers accepted, rejected, edge, and high-cost cases
Evidence status
Sources and claim limits
Sources support the named claims; they do not guarantee the same result in another system.
- [1]Improving support with every interaction at OpenAIfrontline feedback · trace review · evaluation and knowledge operations
OpenAI · Public case · 2026-08-20
- [2]Building effective agentsworkflow versus agent choice · tool design · human review
Anthropic · Published research · 2026-08-20
- [3]Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profilerisk ownership · measurement · human oversight
NIST · Official documentation · 2026-08-20
- [4]Forward Deployed Marketingworkflow ownership · embedded delivery · operating model
Tenten AI · Tenten field method · 2026-08-20
- [5]Structured Outputs guideschema contracts · output validation · refusal handling
OpenAI · Official documentation · 2026-08-20
Related Tenten resources