TFIS · Engagement charter
The Fractional Chief AI Officer who plans to leave.
A reference charter for one job: helping a founder run a one-person company with an AI-agent workforce, then stepping away. The engagement works when the founder no longer needs the CAIO.
Document status. This is a proposed operating charter and role design. It is not a contract, a job advert or permission to take real-world actions. Scope, authority, fees and acceptance criteria are agreed for each engagement. No fixed duration or business outcome is guaranteed.
A 31-second silent explainer, made with HyperFrames. It plays muted when it scrolls into view, unless you've asked your device to reduce motion. Captions are in the player.
Read the video transcript
A big-company CAIO adds a management layer across departments. A one-person company has no layer to add. One human, the founder as Solo Systems Architect, directs an AI workforce.
Move on evidence, not the calendar: Coach, Architect, Govern, Stress-test, Transfer, Exit. Each stage has evidence the founder must show before moving on.
The CAIO is temporary. Controls, records and recovery stay with the founder. During a planned withdrawal, accepted outcomes keep coming with no CAIO rescues. Success is when the founder no longer needs the CAIO.
One accountable human. An AI workforce under real controls. Honest evidence.
01 · Mandate and operating model
Build judgment, not dependency.
The fractional Chief AI Officer helps a founder build the judgment, operating system and practical skill to run a one-person company with an AI-agent workforce. The engagement should leave the founder able to direct, govern, improve and recover the business without ongoing help from the CAIO.
The founder is the Solo Systems Architect (SSA): the human who sets direction, accepts risk and stays accountable. The CAIO is a time-bound outside adviser and delivery partner. Not a replacement founder. Not a permanent management layer.
- Serves an executive team and many departments
- A permanent layer in the org chart
- Helps humans adopt AI tools
- Success: adoption and ROI across the business
- Serves one founder, the accountable human
- Sits outside the company, for a bounded time
- Helps one human direct and govern AI agents
- Success: the founder runs, fixes and governs it alone
What this model means
- One-person company (OPC) describes how the business operates, not its legal form.
- "100% AI employees" describes the workforce. "AI employee" is a working metaphor for a software agent. It is not a claim about employment status or legal personhood.
- The founder stays human. Outside CAIO, engineering, security and legal help are disclosed human inputs, not hidden permanent staff.
- An all-agent workforce is not fully autonomous. Planned human approvals and human-only decisions stay in the design.
- An SSA is always a human. An agent managing other agents is an agent role, not another SSA.
What success has to show
The founder operates without routine CAIO rescue.
The system produces accepted customer or business outcomes within agreed quality, cost and risk limits.
Critical records, controls and recovery paths still work after the CAIO leaves.
Business viability is judged separately. Technical independence can't prove customer demand, revenue or a sustainable margin.
02 · Three boundaries
Three things that are easy to blur.
The CAIO is inside the engagement, working with the founder.
The founder's business, with its own objectives, agents, records and authority.
The temporary arrangement for building that business and the founder's skill. It ends.
Links between independently governed SSA businesses. Not needed for one OPC to succeed.
03 · The six evidence-gated stages
Move on evidence.
Assessment starts at entry and never stops. Stages can overlap, repeat or stop. Timing follows the evidence and the founder's capacity, not a guaranteed 90-day program. Pick a stage to see what has to be true before moving on.
Coach
The CAIO coaches the founder through real work: framing the business goal, the constraints, and how any agent answer will be checked. Capability and dependence are recorded at entry.
The founder can explain the business objective, the important constraints and how an agent's answer will be checked. Initial capability and dependence are recorded.
Leaves behind: a capability baseline and a practice plan.
Tip: use the arrow keys to move between stages.
The six accountabilities behind the stages
They cover three linked layers: human judgment and skill, agent roles and operations, and economic and infrastructure viability.
Establish value and a credible baseline
Pick work that matters to customers or the business. Compare manual work, ordinary automation and a strong single-agent approach before adding multi-agent complexity. Agree accepted outputs, risks, supervision needs and total costs. Keep the evidence when the simpler option wins.
Outputs: a prioritised workflow portfolio, baseline records, business hypotheses and a bounded first pilot.
Develop the founder as the operating principal
Coach the founder through real work in task design, judging evidence, delegation, economics, escalation and recovery. Make decisions inspectable and hand them over step by step. A course, certificate, maturity label or impressive demo can't stand in for practical skill.
Outputs: a capability baseline, practice plan, teach-back records and a dependency register showing what still needs help.
Architect and set up the AI workforce
Design role contracts, workflows, memory boundaries, tool access and operating controls. Say which parts the CAIO builds, which the founder builds and which need a specialist. Test the whole workflow, not just single model answers.
Outputs: architecture and workflow maps, a role registry, an implementation backlog, runbooks and portable configuration.
Govern authority and operational risk
Turn the founder's approved limits into enforced permissions, release gates, budget controls and escalation paths. Bring in qualified specialist review where needed. Keep evidence of deployments, incidents, exceptions and recovery. The CAIO has stop-work authority only if it's expressly delegated.
Outputs: an authority matrix, control and test evidence, a review route, an incident playbook and release decisions.
Show economic and operational viability
Measure accepted outcomes, failures, human effort and full costs. Make ungrounded agent consensus and automation bias visible. Test key assumptions against customer behaviour, accepted deliveries, revenue where it applies, and experiments designed to disprove them.
Outputs: an outcome scorecard, cost ledger, risk and exception register, and a scale, narrow, pivot or stop recommendation.
Transfer capability and close the engagement
Prove the founder can operate while the CAIO steps back. Hand over records, access administration, maintenance and recovery knowledge. Record successful and unsuccessful exits honestly, with clear limits on any future support.
Outputs: the independence test, a handover package, founder acceptance or reservations, an access revocation record and an exit learning record.
Who this fits
A founder willing to learn and stay accountable, a bounded customer or business problem, usable evidence, and enough time and resources for testing and review.
The founder expects passive income without oversight, refuses material controls, or can't supervise the proposed operation.
04 · Decision rights
A title grants no authority.
The founder sets objectives, approves risk limits and commitments, and stays accountable. A role title, a model's judgment or a readiness score grants no authority. What counts is the delegation agreed for the engagement and enforced by the system. Pick a role to see what it can and can't do.
Showing every role.
| Decision area | Founder (SSA) | CAIO | Agents | External reviewer |
|---|---|---|---|---|
| Objectives and commitments | Decides Objectives, risk appetite, spending limits, outside commitments. |
Advises Recommends; doesn't commit. |
Cannot Accept ultimate business risk. |
— |
| Design and build | Approves Scope and deliverables. |
Builds Designs, builds or directs agreed work, only within delegated scope. |
Executes Assigned build tasks. |
Named per deliverable when a specialist is needed. |
| Routine execution | Sets limits Identities, tools, data, budgets. |
Configures within delegation. | Executes Authorised tasks only. Cannot expand their own rights or pass on authority they don't hold. |
— |
| Material assurance | Decides The authorised risk decision. |
Cannot Count their own build review as independent. |
A second model adds evidence, not risk acceptance. | Challenges Material evidence and residual risk, separate from delivery. |
| Suspension and restart | Can suspend Restart needs the designated human decision and evidence. |
Can order suspension only if expressly granted. | Stopped by deterministic controls. | — |
| Changes to authority | Approves Or another expressly authorised human. |
Proposes. | Cannot A shared doc, agent message, confidence score or second model can't authorise a change. |
— |
No invented departments
No internal technology, security, legal, finance or people department is assumed. The CAIO coordinates AI-specific needs. Engineering, legal, compliance and security work is scoped explicitly, never quietly assigned to one person. If a required reviewer isn't available, the affected work is constrained or deferred.
When the founder is away
There's no backup human by default. The design says what may continue under existing authority and what must queue or safe-pause. Pending decisions, expired permissions and open exceptions never become approval through silence. Without an agreed continuity route, the system stops safely and keeps the evidence.
Controls must survive a persuasive prompt
Permissions, budgets and state changes are enforced outside the model. Retrieved pages, shared files and messages from other agents are data, never a grant of authority. Before production, test forbidden reads and writes, prompt injection, stale authority, duplicate requests, budget exhaustion, retry loops and revoked credentials.
The minimum role contract for every production agent
- Purpose and acceptance: business purpose, eligible tasks, expected artefacts, acceptance criteria and banned outcomes.
- Identity and version: stable role and runtime identity, responsible human, model and provider revision, workflow and instruction versions.
- Tools and data: allowed operations, systems, datasets and memory classes; read, write and share rights; credential custody and expiry.
- Resource limits: per-task and total spend, time, tool calls, retries and concurrency, and what happens when they run out.
- Delegation: whether it may sub-delegate, to whom, and the most scope they can receive.
- Evaluation and escalation: checks, human approval points, failure triggers, escalation destination and pending-decision behaviour.
- Lifecycle: approval and review dates, monitoring, suspension, revocation, replacement, export and retirement.
Memory, records and safe recovery
Keep source material, working interpretations, proposed changes and approved records apart. Agent-written memory is a candidate until a required review approves it. Test export and restore instead of trusting a vendor feature.
A safe pause stops new consequential actions, bounds work in flight, protects records and queues decisions for an authorised human. Recovery checks the actual state before retrying, especially when an outside action may already have happened.
05 · Honest measurement
Keep the denominator honest.
Numbers are agreed after a measured baseline and a task-specific risk review. There's no universal autonomy target, agents-per-founder ratio or margin threshold. Agent count, tokens, unattended runtime and "no approvals needed" are not evidence of success on their own.
$9.19
The flattering figure leaves out failed runs, judging, infrastructure, outside help and founder time.
The rules
- Define eligibility before the measurement period. Keep failed, cancelled and timed-out attempts in the reported population.
- Don't relabel hard cases as ineligible after seeing the results. Show every exclusion and its reason.
- A planned approval is not a rescue. A rescue is an unplanned intervention needed to make or recover an acceptable result.
- Report quality, safety, cost, time and human effort separately. A composite score must not hide a serious violation.
- Show cash cost and human time separately, and disclose the rate used to value time. If there are no accepted outcomes, say so instead of showing a misleading ratio.
- Separate setup and research from steady operations. Spread improvement costs only over reuse that actually happened.
The six measures
- Accepted outcomes: deliverables that meet the agreed acceptance criteria, with eligible attempts and escaped errors by severity.
- Completion without unplanned rescue: the share of eligible attempts accepted within delegated limits and without rescue, by task and risk tier.
- Human effort: founder and outside review, approval, rescue, rework and maintenance minutes per accepted outcome, including queued decisions.
- Reliability and recovery: failed, cancelled, timed-out and partial attempts, policy violations, repeat incidents and open exceptions.
- Unit economics: full cost per accepted outcome against the baseline and customer value, with known, estimated and missing costs shown.
- Independence: tasks the founder can change, evaluate, recover, export and govern without CAIO rescue, plus what's still dependent.
Improve the workflow without moving the test
- Compare manual work, ordinary automation and a strong single-agent baseline first.
- Freeze inputs, acceptance criteria, evaluation rules and holdout sets before comparing.
- Give competing workflows equal total budgets, including orchestration, judging, retries and failures.
- Version every workflow, prompt, policy and evidence set. Keep the failures.
- Check outputs with deterministic tests, calibrated model judges and human review. Judge agreement isn't verified correctness.
- Test the chosen version on sealed and genuinely fresh tasks, and report where it fails.
- Promote only with explicit human approval of the exact version and evidence. Test rollback. The simpler baseline may win.
A model judge informs a decision. It doesn't set policy or grant permission. None of this amounts to open-ended recursive self-improvement.
Business reality. A working agent system with no viable market is not a successful business. Operating efficiency, customer demand and business viability are reported separately.
06 · The independence test
Can you run it without help?
Before the CAIO leaves, the founder and CAIO agree the scope, length and conditions of a planned withdrawal. There's no universal observation period. Use this as a self-check against your own system. Your ticks stay in this browser only.
Tick what you can already do without help.
During the real test, every intervention is recorded. A hidden CAIO rescue invalidates the independence claim for that task. Founder acceptance names the scope tested, the evidence, the limits and what's still dependent.
07 · Exits and learning
Three results, kept separate.
The founder meets the agreed operating and governance criteria.
The arrangement ends, with or without independence.
Customer value and viable economics are shown to the agreed standard.
Exits are classified honestly: partial independence, pivot, founder choice, technical failure, business failure or poor model fit. Negative and partial exits teach a lot. They aren't automatically successful engagements.
At handover, the founder receives the architecture, role and workflow registries, approved policies, evaluation suites, runbooks, cost records, incident history, dependency inventory and admin ownership. CAIO access that's no longer authorised is revoked and the change is checked. Support after exit needs a separate agreement.
Learning that respects sovereignty
Every exit should produce a learning record. That never authorises public sharing, moving memory between clients, or reusing private data, credentials or proprietary work.
- L1Client operational records stay under the client's agreed control.
- L2Confidential engagement case records need agreed ownership, access and retention.
- L3Permissioned general patterns strip client-identifying and confidential content, and keep their limits and counterexamples.
- L4Public case studies need explicit approval of the content and the audience.
Federation is optional
A multi-SSA extension connects separate human principals and their agent workforces. Each business keeps its own objectives, data, credentials and policy, and it's never presented as departments inside one company. A receiving agent never inherits the sender's full authority, and protocol messages don't expand delegated authority. Start with one bounded exchange, and only if the single OPC really needs it. A marketplace or shared platform is not an entry requirement.
What the role won't do
It doesn't promise revenue, replace the founder's judgment, certify legal compliance, automate every activity or require a federation platform. Broader production engineering, regulated advice and ongoing managed operations are included only when scoped separately. Readiness tools such as SSA-CMM are diagnostics: they don't grant permissions, prove compliance or prove viability.
08 · Falsifiability
What would prove this wrong.
The one-person-company model should be revised or narrowed if evidence keeps showing any of these:
The founder can't sustain the supervision the system needs.
The human support required wipes out the leverage the model claims.
Reliability and economics don't meet what the business needs.
Backcasting from a desired future describes an aspiration and a route to test. It isn't observed proof. SSA-0, my own prototype, is a test bed, not a template: evidence from one prototype is tested before it becomes a general rule.
09 · Glossary
The words, in plain terms.
Solo Systems Architect (SSA)
The human founder who sets direction, accepts risk and stays accountable for a business run with an AI workforce. Always a human. An agent that manages other agents is an agent role, not an SSA.
One-person company (OPC)
An operating model with one human founder and an AI-agent workforce. It describes how the business runs, not its legal form.
AI employee
A working metaphor for a software agent with a defined role. Not a claim of employment status or legal personhood.
Fractional CAIO
A time-bound outside human adviser and delivery partner who builds the founder's capability and then leaves.
Safe pause
A controlled stop: no new consequential or out-of-scope actions, work in flight is bounded, records are protected and decisions queue for an authorised human. Silence never counts as approval.
Rescue vs planned approval
A planned approval is a human check designed into the workflow. A rescue is an unplanned intervention needed to make or recover an acceptable result. Only rescues count against independence.
Accepted outcome
A customer or business deliverable that meets the acceptance criteria agreed before the work.
Full cost per accepted outcome
All costs (models, every agent and judge call, retries and failures, infrastructure, tools, maintenance, founder time and outside help) divided by accepted outcomes. Cash and time are shown separately.
Honest denominator
The attempt population defined before measuring, including failed, cancelled and timed-out attempts. Hard cases aren't relabelled as ineligible after the fact.
Independence test
A planned CAIO withdrawal in which the founder shows they can teach back, change, evaluate, recover, explain and export the system without rescue.
SSA-CMM and SSA-0
SSA-CMM is a readiness diagnostic for spotting development needs. It grants nothing. SSA-0 is my own prototype identifier, not a maturity level and not a claim that another business shares my authority.
Federation
Optional, scoped collaboration between independent SSA businesses, each keeping its own data, credentials and policy.
10 · Talk to me
Want to run your company this way?
If you're a founder thinking about an AI workforce and want to stay the accountable human, I'd like to hear what you're building. No pitch deck needed.