A customer asks for a software architecture review. One AI agent researches the domain, another drafts an offer, and a third proposes a delivery schedule. Each result looks reasonable. Yet the offer promises a deadline the owner cannot meet, the draft includes material the customer never authorized for external processing, and the support agent later assumes a service level that was never agreed.
Humans have a long tradition of treating instruction manuals as optional—right up to the moment a device starts making an expensive noise. Confidence, unfortunately, is not an operating procedure. Before giving AI agents the same freedom, it may be worth documenting how the business is supposed to work.
The missing piece is a shared understanding of how the business works: which promises it makes, who can make them, what evidence is required, and how a case moves from first contact to a completed service.
Business Engineering provides a framework for designing that shared operating structure. For a solo business supported by AI agents, the resulting agreements, models and rules belong in a business manual. The manual contains the process landscape, detailed business process models, working instructions and authority rules. It evolves with the business and gives every process instance a precise operating baseline.
This article develops an illustrative Homann Software Manual 2026.1.0. It is a proposed example for a software architecture and engineering solo business, not a statement that Homann Software has adopted these internal procedures. Its release format is Year.Minor.Patch, with explicit compatibility rules inspired by Semantic Versioning. The example connects the business model, capabilities, responsibilities, information objects, supporting applications and performance measures to a process landscape and BPMN model. The focus is how the business operates and how its rules evolve.
The current trend: agent orchestration becomes process engineering
Homann Software combines systems architecture, software architecture and software engineering with a human-centred approach. In the Guardian Angels article, we explored how AI agents could support independent work. Here, we take the next step: designing the business processes, responsibilities and working rules that make that support useful in everyday operations.
Three developments make this timely. First, agent adoption is moving into end-to-end business work, where a useful answer must become an accepted outcome. Camunda's January 2026 survey of 1,150 senior IT leaders, business decision-makers and architects reported that 73% saw a gap between their agentic AI ambitions and reality. This is vendor-sponsored enterprise research, not evidence about a typical freelancer. It nevertheless illustrates the operational difficulty of connecting experiments to dependable work.
Second, process redesign is becoming central to that discussion. Camunda's September 9, 2026 release reports that 72% of organizations surveyed said process-related challenges had caused AI initiatives to fail. Its September 16 analysis identifies the survey population as large companies: 1,000 process decision-makers and 5,000 employees, across four countries. These self-reported results do not establish causation or predict a solo firm's return on investment. They support a narrower observation: adding AI to an unclear process leaves the process unclear.
Third, agent engineering increasingly depends on external state and verifiable results. Anthropic's work on long-running harnesses describes structured progress records and incremental work across sessions. Its January 2026 evaluation guidance explains why agent tests must consider multi-turn behavior and the resulting state. A business manual extends those ideas to business responsibilities: which outcome counts, which records must survive, and where work must stop for a decision.
More recent engineering accounts reinforce the separation of responsibilities. Anthropic's April 2026 Managed Agents design separates the session record, harness and execution environment; its May 2026 containment article describes enforcing limits on what agents can access. A written manual gives those boundaries business meaning, while software must enforce them.
My conclusion from these sources is that versioned business processes are a strong foundation for the next stage of the agent-supported solo business. This is an architectural judgment, not a claim that every independent business needs an enterprise workflow platform.
Business Engineering is the organizing framework
Business Engineering brings the design of a business and its transformation into one coherent approach. The St. Gallen account by Winter, Müller and Gericke connects strategy, organization and systems, alongside leadership, behavior and power. It combines business, change-management and engineering perspectives. This is an established framework, described in their 2008 paper; the current application here is the introduction of AI agents into a solo business.
For this example, three questions guide the design. Strategy: which customer problem will the business solve, with what service promise and economic assumptions? Organization: which capabilities, roles, processes and decisions make delivery possible? Systems: which information, applications and technical controls support those activities? Human adoption cuts across the questions: the owner must be able to review the work, customers must understand the service, and delegating preparation must not blur decision authority.
The business manual records the agreed operating baseline across these views. A Business Model Canvas helps express the commercial assumptions. Capability and responsibility models describe what the business can do and who decides. BPMN models the work. Information and application views explain how records and tools support it. Metrics show whether a change improves the service. Business Engineering connects these artifacts and guides the move from the present operating model to a deliberately designed target.
Suppose the present offer process is largely manual: the owner interprets a brief, drafts the proposal, reviews it and sends it. The proposed target delegates research and drafting to scoped agents while preserving owner approval. Before changing anything, record the existing lead time, review effort and common causes of rework. Then identify what must change together: preparation instructions, authorized information access, case records, the review packet and owner working habits.
Pilot that target on a bounded set of cases. Compare review effort, quality, exceptions and customer understanding against the original baseline. Adopt it only when the owner accepts the evidence and can operate the revised process. The change record explains what was tried and learned; a new manual release states which rules now govern normal work. An attractive diagram is a design artifact, while a completed, evaluated transition establishes the adopted operating model.
Begin small so the manual does not block the business
For a solo business, the full set of models in this article may be too much at the beginning. Preparing a complete capability catalog, RACI matrix, application architecture and KPI system before serving the first customer can consume the very capacity the business needs to get started. The Homann Software Manual is an example of what can develop over time, rather than a checklist that must be completed before work can begin.
Start with a short working manual for one service: the customer outcome, the basic path from inquiry to delivery, who approves commitments, what agents may prepare, which information they may use and where decisions and results are recorded. Describe what happens when scope is unclear or the owner is unavailable. A simple process sketch can be sufficient initially; add a detailed BPMN model when branching, handoffs or planned automation make it useful. Necessary permissions and approval boundaries apply from the first case, even when the documentation is brief.
Develop the remaining elements through continuous improvement. When repeated clarification causes delay, improve the brief and qualification rules. When approval responsibilities become confusing, add a responsibility matrix. When information is duplicated across tools, clarify the information model and system of record. When work accumulates, introduce capacity and lead-time measures. Each addition should resolve an observed problem or support a concrete next step.
Keep a small improvement backlog and review it alongside actual customer work. Choose a useful change, try it, assess its effect and incorporate it into the next manual release. It is acceptable to leave a section undeveloped while its purpose is unclear. Mark it as planned rather than presenting a proposed rule as adopted practice. This lets the manual grow with experience and avoids turning Business Engineering into a barrier to starting the business.
A manual makes the business understandable
A process landscape shows the business at a glance. It groups management processes, customer-facing core processes and support processes. A business process model then describes how a particular outcome is reached: triggers, activities, decisions, responsible roles and exceptions. Working instructions explain the details of an activity, such as how to assemble a review packet or reproduce a defect.
Those layers answer different questions. A founder needs the landscape to see whether the business has a workable way to acquire customers, deliver services and remain solvent. An agent preparing an offer needs the specific C02 process contract and its working instruction. The customer needs an understandable commitment and a dependable point of contact.
The manual should therefore be easy for people to read and sufficiently structured for software to select the relevant rules. A readable handbook, BPMN files, working instructions and a release record can be enough initially. Store them together under version control. The handbook explains the business rules; the models show responsibilities, decisions and handoffs. Any inconsistency between them blocks release until the owner resolves it.
Figure 1. Stable process identifiers connect the landscape to models, work instructions, evidence and future revisions.
Choose the first agent contribution by business value
The first useful question is which piece of work consumes effort or causes friction. A recurring research summary, proposal draft or acceptance packet may be a suitable starting point when its inputs are available and the owner can inspect the result. A task whose success cannot yet be described needs clarification before delegation.
Evaluate the candidate in its whole process. Does it occur often enough to justify setup and maintenance? Are the relevant facts accessible within the permitted scope? Can someone recognize a good result without repeating all the work? What happens if the output is wrong or incomplete? How much review and correction does it create? These questions help identify an improvement worth trying.
In the architecture-assessment example, drafting a proposal from a qualified brief has a recognizable output and a natural owner review point. Granting an agent freedom to negotiate scope and commit to a delivery date requires a much broader operating design. The first pilot can therefore assist preparation while the owner continues making the commercial decisions.
Anthropic's foundational agent guidance distinguishes predefined workflows from agents that dynamically choose their steps, and recommends increasing complexity only when it improves the task. The article was first published in December 2024 and is used here for that architectural principle, not as a current product comparison. Applied to a solo business, it suggests starting with the simplest useful arrangement: a person using an assistant, a bounded preparation workflow, or an agent with a clear task and stopping conditions.
Several named agent roles do not require several independently operating agents. One assistant may support research, drafting and record preparation in separate tasks. Add coordination machinery when the work genuinely needs it and when its extra cost and review burden can be assessed.
Inside the Homann Software Manual 2026.1.0
The example manual begins with purpose and scope: help a solo software architecture and engineering business deliver useful, maintainable systems while keeping the owner accountable for commitments. It covers discovery, offers, delivery, acceptance and support. It also covers the supporting work that makes delivery possible: finances, access management, knowledge, backups and continuity.
Its process landscape contains three management processes: M01 Strategy and Service Portfolio, M02 Quality, Risk and Capacity, and M03 Manual and Agent Governance. The core chain is C01 Discover and Qualify, C02 Prepare and Approve an Offer, C03 Design, Build and Verify, C04 Obtain Acceptance and Close, and C05 Support and Improve. Supporting processes are S01 Finance and Administration, S02 Data and Access, and S03 Knowledge and Business Continuity.
One person may perform several roles. That does not erase the distinction between them. The owner chooses priorities and accepts business risk. The architect shapes responsibilities and dependencies. A delivery agent prepares implementation and tests. An operations agent assembles records and exceptions. A customer accepts the agreed result. An AI agent can assist a role without becoming the accountable business owner.
For engineering delivery, the manual connects the customer use case to domain responsibilities, architectural decisions, quality requirements, UX/UI where relevant, implementation and test evidence. That creates a route from the customer's problem to the delivered result. An agent's task is meaningful because it contributes to that route.
The complete example manual provides a usable starting point, including a nine-part business model, capability catalog, RACI matrix, process cards, decision table, information and application architecture, quality requirements, metrics, risk register and improvement routine. Its numeric budgets and review targets are illustrative configuration choices, not reported company figures or market benchmarks.
A simple manual package and table of contents
What should a founder actually put into the manual? Start with one readable handbook as the entry point, then keep detailed models, instructions and reusable forms beside it. The following is a suggested layout for a growing Homann Software Manual. It shows how the material could be organized; the article download uses a smaller example package.
├── README.md Entry point, scope and reading guide
├── handbook.md The readable business manual
├── release-manifest.json Version and included artifact revisions
├── CHANGELOG.md Adopted changes and compatibility notes
├── 01-strategy/
│ ├── business-model.md Customers, value, revenue and costs
│ └── services-and-capabilities.md
├── 02-processes/
│ ├── landscape.md Management, core and support processes
│ ├── C02-process-card.md Trigger, inputs, outcome and exceptions
│ └── C02-offer.bpmn Detailed flow when useful
├── 03-roles-and-rules/
│ ├── responsibilities.md Owner, agent and customer decisions
│ └── agent-boundaries.md Permitted work, access and stopping rules
├── 04-working-instructions/
│ └── C02-prepare-offer.md How to perform the preparation activity
├── 05-information-and-systems/
│ ├── records-and-ownership.md Information objects and systems of record
│ └── tools-and-continuity.md Applications, access and manual fallback
├── 06-templates/
│ ├── customer-brief.md
│ ├── agent-task-packet.md
│ └── owner-decision.md
└── 07-quality-and-improvement/
├── measures-and-risks.md
└── improvement-backlog.md
The handbook explains the operating model and links to the detailed files. A process card states what a process must achieve; its BPMN model shows the route; a working instruction explains how to perform an activity; a template provides a reusable form. Give related artifacts the same stable process identifier, such as C02, so readers can follow the connection without guessing.
The handbook itself can use this simple table of contents:
- Purpose, scope and release: what the business does, whom the manual serves, the accountable owner and the current version.
- Business model and service promise: customers, value proposition, services, capabilities, commercial assumptions and capacity.
- Process landscape: the management, core and support processes, their identifiers and the customer journey connecting them.
- Process descriptions: triggers, inputs, outcomes, responsibilities, handoffs and exceptions; links to BPMN models where useful.
- Roles, decisions and agent authority: who prepares, who approves, what agents may access, budgets and when work must stop.
- Working instructions and templates: practical steps and reusable briefs, task packets, proposals and decision forms.
- Information and application support: which records matter, where authoritative state lives, access rules and supporting tools.
- Quality, risk and continuity: acceptance criteria, evidence, exceptions, fallback procedures and recovery responsibilities.
- Performance and continuous improvement: selected measures, review routines, lessons from cases and the improvement backlog.
- Release and change management: Year.Minor.Patch rules, compatibility decisions, change history and treatment of open cases.
These are headings to grow into, not ten documents that must be completed before starting. A first version can contain just README.md, handbook.md and CHANGELOG.md, with the essential process sketch, owner approvals, agent limits, case-record location and fallback described inside the handbook. Split a section into its own file when repeated use or increasing detail makes that helpful. Add the manifest when the release contains several independently maintained artifacts that must be identified together.
Keep rules and reusable forms in the manual package. Store completed customer briefs, proposals, approvals and acceptance evidence in a separate, access-controlled case area. Each case references its governing manual release; the manual contains links to the record locations and ownership rules. Credentials belong in appropriate secret storage, and customer-specific material belongs within its permitted access scope. A released manual remains stable while new case evidence accumulates and proposed improvements are reviewed for a later release.
Business Engineering connects business value, organization, information and IT
BPMN describes how work proceeds. The business manual also needs to explain why that work matters, who is responsible, what information it changes and which systems support it. These are complementary views of the same business. Business Engineering uses these connected views to design and introduce a change; business informatics supplies many of the modeling methods used to assess its effects.
Start with the business model. Strategyzer's Business Model Canvas organizes nine connected elements: customer segments, value propositions, channels, customer relationships, revenue streams, key resources, key activities, key partnerships and cost structure. For the illustrative Homann service, the customer is a software team facing architectural uncertainty; the value proposition is a practical assessment with prioritized recommendations and decision evidence. Revenue comes from an agreed assessment fee. Owner time, preparation, agent usage and rework belong in the cost view. The manual includes all nine elements as hypotheses to validate, not assumptions that become true merely because they have been documented.
Next distinguish business capabilities from processes. Architecture assessment is an ability the business must have; C01–C04 describe the customer journey through which it provides that service. This distinction helps an owner identify a real bottleneck: insufficient review capacity, unavailable domain expertise or a weak acceptance process. Adding agents is useful when it addresses that bottleneck and preserves the service promise.
Figure 2. A conceptual Business Engineering view connects strategic value, organization and system support, with information as the link between work and applications. This graphic uses plain labels rather than formal ArchiMate notation.
Enterprise architecture makes these dependencies visible. ArchiMate provides a language spanning business, application and technology concerns. A solo business can start with a smaller mapping: the C02 offer process uses a customer brief, proposal and decision record; a case-management system holds case state; a document repository holds released manuals and proposal snapshots; an agent workspace prepares drafts; an approved communication service sends the offer. An AI chat transcript should not be the only record of a business decision.
| View | Example in the manual | Question it answers |
|---|---|---|
| Business model and value | Architecture assessment with actionable recommendations | Why will a customer buy this? |
| Capabilities and organization | Assessment, offer preparation and owner review capacity | Can this business deliver the promise? |
| Process and decision | C02 BPMN flow plus explicit preparation rules | How does work proceed, and when must it pause? |
| Information | Brief, proposal version, approval and acceptance record | What must be known and preserved? |
| Application support | Case system, document repository and scoped agent workspace | Where is work supported and state recorded? |
| Performance and improvement | Lead time, review effort, rework and accepted outcomes | Is the operating model improving? |
Responsibility must also be explicit. A RACI matrix distinguishes the role performing an activity (Responsible), the role answerable for its result (Accountable), people whose input is required (Consulted) and those who need an update (Informed). In this manual, every business activity has one accountable human role. An agent can prepare an offer as a responsible execution role, while the business owner remains accountable. Customer acceptance is a separate customer decision; an internal RACI matrix cannot assign that decision to the supplier.
Separate business decisions from process flow
A gateway in BPMN shows where the route changes. The criteria for taking that route belong in explicit business rules. OMG's Decision Model and Notation provides a separate standard for describing such decisions and can complement BPMN. The following is a plain business decision table inspired by that separation; it is not an executable DMN model.
| Priority | Condition for C02 preparation | Result |
|---|---|---|
| 1 | Required information may not be used for this task | Pause and resolve permitted use |
| 2 | Required brief or delivery-capacity information is missing | Request clarification |
| 3 | Preparation budget is exhausted | Stop preparation; owner decides next step |
| 4 | All preparation conditions are satisfied | Prepare the draft for owner review |
Apply the rows in order and take the first matching result. If an input is unknown, the preparation conditions are not satisfied. None of these results authorizes sending: the owner still decides whether to approve, revise or decline at the review step. Keeping preparation eligibility separate from commercial approval prevents a checklist from accidentally becoming authority to commit the business.
The information model supports that distinction. A customer has inquiries; a qualified inquiry can lead to a case; a case contains proposal versions; a decision references one exact proposal version and its recipient. Acceptance references the agreed deliverable. Changing the proposal creates another version and requires another decision. This small model gives the approval rule a concrete object to act on.
The manual also links requirements and service quality to those objects. For the use case UC-C02-01 Prepare an Offer, the postcondition is a reviewable draft with explicit scope, exclusions, price, schedule and acceptance criteria. A confidentiality requirement restricts the material agents may access. A traceability requirement links an approved offer to its brief, proposal snapshot and owner decision. A continuity requirement defines what happens when the owner or an application is unavailable. These requirements become walkthrough questions and, if the workflow is automated, implementation acceptance criteria.
Measure business outcomes and improve the operating model
An agent-supported business needs business measures. Record offer lead time from qualified brief to confirmed send or decline, owner review effort, revision frequency, first-pass acceptance and preparation cost per accepted outcome. Define the period, source and denominator for every measure. Report offers and declines separately; do not make declining unprofitable work look like operational failure. A zero denominator produces an undefined ratio, not a perfect score.
Cost assessment should include external spending, agent usage, rework and owner capacity. Capacity consumption and accounting profit answer different questions and should be reported separately. The manual proposes measures but invents no observed results or industry targets.
Use those observations in a Plan–Do–Check–Act cycle: plan an improvement from actual case evidence, try it on a controlled scope, compare the outcome against the previous baseline, then adopt, revise or abandon it. ASQ describes PDCA as a repeating method for improvement. In this manual, an adopted behavioral change becomes a new minor release with a compatibility assessment and an explicit decision for open cases.
Model the offer process before automating it
Consider C02. Its trigger is a qualified customer request. Inputs are the customer brief, consented contact details and available delivery capacity. Its outcome is an approved offer or a recorded decision to decline. Success means the customer receives the intended, approved offer and the business can show how its commitments were authorized.
The agent drafts scope, assumptions, exclusions, price and acceptance criteria. A deterministic preparation check verifies required fields and the task budget. The owner reviews the customer-facing commitments. The BPMN model uses an exclusive gateway for the owner's decision: revise, decline or approve. Revision returns to drafting; decline closes the case; approval permits the next activity to send the approved offer.
Figure 3. BPMN 2.0 collaboration model for C02. The customer is a separate participant; business-owner and agent/system lanes belong to the business pool. Only message flows cross between participants.
The downloadable BPMN 2.0 XML contains the model and diagram coordinates. BPMN is the appropriate notation here because the subject is a business workflow involving people, systems and a customer. OMG's BPMN 2.0.2 specification defines the notation and interchange format. The example is a descriptive, non-executable model; deploying it in a workflow engine requires engine-specific bindings and behavior. The graphic shows preparation and the owner's decision paths; the exception rules below are specified in the manual and are not expanded into additional model branches.
The approved proposal is an immutable snapshot. Changing its recipient, scope, price or delivery date requires another review. A production sender must check the authenticated approval, proposal digest, recipient, expiry and exact manual version before acting. Customer text and model output are input data; neither can grant tool permissions or rewrite the released process.
The happy path is only part of the process. Missing consent pauses preparation. An exhausted budget stops agent work. An unavailable owner leaves the case waiting rather than turning silence into approval. If the send result is uncertain, the system reconciles using the provider's evidence before retrying. A manual explains those business decisions; the runtime must implement them.
Follow one customer case through the whole business
Imagine a fictional customer, Northstar Tools, asking whether its growing order-management system needs to be split into services. The name and engagement are illustrative. The proposed Homann service is an architecture assessment that produces findings, prioritized recommendations and decisions the customer can act on.
In C01, the owner clarifies the actual problem: slow feature delivery, unclear responsibilities or operational instability may require different responses. The brief identifies the people affected, relevant use cases, system boundaries, available evidence and restrictions on access. An agent can organize authorized material and draft questions; the owner confirms whether the engagement fits the business and available capacity.
In C02, the preparation task turns that brief into a proposal. The offer states what will be assessed, what remains outside scope, how findings will be presented and how acceptance works. A phrase such as “improve scalability” becomes specific enough to review: assess the agreed workloads and constraints, identify evidence gaps, and provide recommendations with assumptions. The owner checks price, schedule and commitments before the approved version is sent. If the customer requests implementation as well, the scope is revised and reviewed again.
In C03, the assessment connects the customer's use cases to domain responsibilities, dependencies, architectural choices and quality requirements. Agents may summarize dependencies or draft alternative designs, but findings still need evidence and professional judgment. The delivery baseline records what was examined, what was observed, what remains uncertain and why a recommendation follows. A polished report alone does not show that the agreed assessment has been performed.
In C04, the customer reviews the deliverable against the agreed criteria. An acceptance packet makes that review easier by linking each promised result to its evidence and recording remaining limitations. A gap within agreed scope returns to delivery for correction. A newly requested capability goes through scoping rather than becoming an invisible addition to the original commitment.
In C05, a follow-up issue is assessed against the agreed support scope. Suppose the customer cannot apply a recommendation because a dependency was not documented. The owner determines the appropriate response, prepares or reviews a correction, and verifies the result. The recurring lesson may be a better dependency checklist in C03 or a clearer handover instruction in C04. That lesson enters the improvement backlog and, if adopted, the next manual release.
The case shows why the landscape matters. Local improvements to drafting, assessment or support must still preserve the customer's journey and the evidence linking one stage to the next. The manual provides that continuity even when the same owner performs several roles.
Year.Minor.Patch needs an explicit compatibility contract
The requested version format is straightforward to read: 2026.1.0 means the 2026 manual, its first numbered process revision, and patch zero. But strict Semantic Versioning 2.0.0 gives the major number a specific meaning: incompatible API changes require a major increment. A calendar year cannot reliably serve that purpose, because a breaking business change can happen in October.
This example therefore uses a calendar-based Year.Minor.Patch convention with SemVer-inspired change rules. It deliberately does not claim full SemVer compliance. If tooling requires strict SemVer guarantees, give the process contract a separate MAJOR.MINOR.PATCH version and keep the calendar label as the manual release identifier.
| Release part | Rule in this example | Example |
|---|---|---|
| Year | Next annual baseline; review compatibility explicitly; reset to .0.0 |
2026.3.2 → 2027.0.0 |
| Minor | Change business behavior or add a process; reset patch; declare compatibility | 2026.1.0 → 2026.2.0 |
| Patch | Editorial corrections only; unchanged enforceable contracts | 2026.1.0 → 2026.1.1 |
A new, optional process can be additive. Changing an existing process's required input, approval, output, sequence or budget is conservatively classified as breaking in this manual convention. A breaking minor release requires a migration note. The version number identifies the release; the manifest and contract comparison describe compatibility.
Do not quietly change a released file. Publish a new release. Keep the previous artifact available for cases already bound to it. The annual baseline also needs a decision about open work; January 1 does not make old customer commitments disappear.
The download also includes an editable UML release lifecycle, showing drafting, review, release and supersession. Superseded releases remain available for bound process instances.
A process instance must know which manual governs it
Suppose offer offer-0042 starts under Manual 2026.1.0. Tomorrow, Manual 2026.2.0 lowers the preparation budget. The offer should not switch rules merely because an agent asks for the latest manual. It remains bound to its original version and content digest until a deliberate migration decision says otherwise.
The case record should identify the case, stable process ID and exact manual release. It should also link the model, working instruction, evidence and owner decisions used for that case. A release record lists which versions of those documents belong together, so a later review can reconstruct the rules that applied.
For example, the owner might record the following for an offer already in preparation:
| Case record | Example |
|---|---|
| Case | Offer 0042 for an architecture assessment |
| Governing process | C02 — Prepare and Approve an Offer |
| Manual release | Homann Software Manual 2026.1.0 |
| Current activity | Owner review of scope, price and delivery date |
| Required evidence | Customer brief, proposal snapshot and decision record |
| Release-change decision | Continue under 2026.1.0; no migration authorized |
When 2026.2.0 is released, the owner asks whether changing this case's rules would alter its commitments, remaining budget or acceptance criteria. If so, the case either continues under the original release or pauses for an explicit migration decision. Any affected customer commitment needs the relevant agreement and renewed approval. A compatible release makes migration possible; it does not make migration automatic.
This discipline does not require a workflow engine at the outset. A small business can maintain the case record and release history in its existing work-management system. Automation becomes useful when volume or complexity justifies it. The business model should remain understandable even when a person performs the steps manually.
The manual and model download includes the standalone handbook, BPMN XML and editable lifecycle diagram source. The BPMN XML passed validation against the official OMG XML schemas, along with structural checks for identifiers, references, lanes and diagram coordinates. These checks establish a valid exchange file; they do not establish deployed workflow behavior or the effectiveness of a particular AI agent.
Give the agent a task packet it can actually use
The full manual is a reference, while a task packet selects the material relevant to one piece of work. For an offer-preparation task, the packet should make the current case and permitted contribution explicit. This can be a short structured document attached to the case; it does not require a new platform.
| Task-packet field | Example for C02 |
|---|---|
| Case and baseline | Offer 0042, C02, Manual 2026.1.0 |
| Intended result | Reviewable offer draft with scope, exclusions, price assumptions, schedule and acceptance criteria |
| Approved inputs | Qualified brief, available-capacity information and authorized service-description material |
| Relevant instructions | Released C02 process card and offer-preparation working instruction |
| Permitted contribution | Research authorized material, draft the proposal and identify missing information |
| Limits and stopping conditions | Assigned preparation budget; pause on missing inputs, uncertain permission or unresolved constraints |
| Required handoff | Proposal version, evidence links, assumptions, unknowns and requested owner decision |
Figure 4. The C02 preparation task turns relevant released rules and case facts into reviewable work. The owner decides; the case records the outcome and any confirmed action.
This packet reduces ambiguity. The owner can inspect whether the task has the right inputs; the agent has a defined contribution; and the result can be compared with the requested output. Relevant manual sections should remain retrievable by exact release rather than being reconstructed from a previous conversation.
Separate normative instructions from case material. A customer's brief may contain requested outcomes and useful facts, but it cannot change the business's approval rules. An agent-generated summary may help navigation, but unresolved discrepancies must be checked against the released source. The packet should identify where the authoritative rule and original evidence can be found.
This also supports handovers. If the owner resumes a case after several days, or switches preparation tools, the case should still explain what was requested, what was produced, what remains unresolved and which decision is next. Durable business records make continuity possible without expecting a model's conversational memory to carry the entire engagement.
Plan for exceptions and a workable manual fallback
The operating model needs a route for work that cannot continue normally. Classify the blockage before reacting: is information missing, a commercial decision needed, the preparation budget exhausted, a tool unavailable, or the result of an external action uncertain? Those situations need different next steps.
Missing information leads to clarification. A changed commitment leads to owner review. A failed preparation tool can lead to manual drafting or rescheduling. An uncertain email submission leads to reconciliation using available provider records. The case records the issue, current state, known external effects and next responsible role. An agent should not repeatedly attempt the same step merely because the intended outcome has not yet been confirmed.
A solo business should preserve a practical fallback for its important service. If the agent workspace is unavailable, the owner can use the qualified brief and latest draft to continue preparation. If the document repository is unavailable, the business needs a way to retrieve the released baseline and essential case records. If the owner is unavailable, activities requiring the owner's decision remain waiting, and customer communication follows the previously agreed arrangement. An agent cannot compensate for an absent business principal by granting itself more authority.
Provider and model changes deserve review as well. A new model, prompt, tool permission or connector can change the result even when the high-level BPMN flow is identical. Record the configuration used, try representative cases and assess whether the change affects the adopted operating rules. A vendor update does not by itself authorize wider customer-data use or new business commitments.
NIST's AI Risk Management Framework and its Playbook organize risk work through Govern, Map, Measure and Manage. They provide a useful voluntary reference for relating responsibilities, context, evaluation and responses. The example manual uses a smaller, case-based routine suited to the owner; it makes no claim of NIST certification or demonstrated compliance.
Keep the handbook useful as it grows
Documentation maintenance becomes part of ordinary work when a change request has a clear entry point. An owner or agent records the observed problem, affected process, case evidence and proposed improvement. The owner reviews whether changing the rule is worthwhile and whether the proposal belongs in the handbook, a process model, a working instruction or temporary case notes.
Place lasting rules where people expect to find them. The process card identifies the outcome and responsibility; the BPMN model shows the route; a working instruction explains the activity; the release record links the adopted revisions. Reference shared rules rather than copying them into every document. If copies are necessary for practical use, identify their source and release so they can be checked together.
Before releasing a change, review the affected artifacts and open cases. Does the model still match the instruction? Are the decision criteria understandable? Can the owner retrieve the previous baseline? Has a new permission or commitment appeared? Are unresolved proposals clearly marked as drafts? The review should be proportionate to the change: correcting a spelling error needs less effort than changing approval or acceptance behavior.
Make the new release easy to adopt. A concise change note identifies the version, effective use for new work, affected processes, reason for the change and treatment of existing cases. It tells the owner and any assisting agent what they need to do differently. An annual review can consolidate the baseline, while useful improvements can be introduced throughout the year.
Let agents improve the manual through a controlled feedback loop
A manual should evolve when actual work reveals a better process. An agent can notice repeated clarification requests, a test that catches the same defect, or support cases that expose a missing acceptance criterion. It can propose a change with case references, expected benefit, impact on existing work and a draft model revision.
The owner decides whether to adopt it. Review the handbook, process model and working instructions together. Walk through representative cases, including revisions, declines and exceptions. For an LLM-backed implementation, evaluate representative briefs, missing inputs, conflicting instructions and attempts to bypass approval. Check both the agent's reasoning trajectory and the business result. A valid BPMN diagram alone does not establish that a chosen model behaves reliably.
Release the approved change as a new manual version, then use it for new cases. Existing cases either finish under the old release or migrate through a recorded decision. Rollback changes which release new cases use; it does not reverse customer emails or other completed effects. If a release contains a dangerous rule, suspend affected work and assess open cases explicitly.
For a solo business, a weekly review can be modest: inspect unresolved exceptions, customer feedback, review time, rework and cost per accepted outcome. Measure whether the manual reduces confusion and effort. A growing document count is not evidence of a better business.
Expand in stages, guided by actual work
The following path is an illustrative adoption sequence, not a timetable every founder must follow. Progress depends on customer work, capacity and observed friction. A business can stay at a simpler stage while it continues to work well.
| Stage | Useful additions | Evidence for moving further |
|---|---|---|
| First service and first cases | Short service promise, basic process sketch, owner/agent boundaries, case record and release label | The owner can explain and complete the customer journey |
| Repeated engagements | Process cards, reusable brief and offer instructions, simple decision rules and selected BPMN detail | Repeated uncertainty or rework makes a shared description valuable |
| More tools or delegated work | Responsibility matrix, information ownership, application responsibilities and a structured task packet | Handoffs, duplicate records or unclear permissions need coordination |
| Higher volume or complexity | Capacity limits, defined metrics, exception routines and more precise models | Waiting, quality variation or recovery needs justify added controls |
Figure 5. The handbook grows in response to useful lessons from real work. These stages are guidance rather than prerequisites or a mandatory timetable.
During the first cases, write down what is actually being done and where understanding breaks down. During repeated work, standardize the parts that have become stable. When tools or collaborators are added, clarify the handoffs and records they share. When volume grows, use measures to decide whether the constraint is preparation, review, customer response or delivery capacity.
The review should include the owner's workload. Faster draft generation is helpful only if it reduces total effort or improves an accepted outcome. If it creates a queue of proposals requiring lengthy correction, the next improvement may be better inputs, narrower delegation or fewer simultaneous cases. Expanding the agent roster would not resolve the underlying review constraint.
For each stage, retain an improvement backlog and release only adopted rules. Proposed future structures can remain in a clearly marked design area. This distinction gives the business room to experiment while keeping its current operating baseline understandable.
Apply Business Engineering to one complete customer journey
A founder can begin with a single paid service, such as an architecture assessment. Map its path from inquiry to acceptance and support. Write down what the customer receives, which decisions remain with the owner, what the agent may prepare, and what happens when the normal path fails.
Describe the present workflow, design a manageable next step and try it on a realistic customer case. A first Manual 2026.1.0 can be a few pages containing the service promise, a simple process overview, owner approval and agent boundaries, basic case records and a release convention. Add BPMN, richer process cards and other models as specific needs emerge. Record which release governs each new case and keep the evidence close to the case rather than relying on an agent's memory.
The business manual earns its place by making work easier to understand and safer to continue. It gives the human owner a clear view of commitments and gives agents a well-defined contribution to make. That is a practical way to turn the promise of an agent-supported solo business into repeatable service delivery.
Research date: October 12, 2026. The manual is an illustrative design. Research findings, proposed operating rules and validated model files are distinguished throughout.