# C2Consultants We empower people to manage AI that does the work. Describe the outcome. AI drafts the workflow and runs the routine steps on your own servers. Your people approve what matters, and every action leaves a record. C2Consultants, LLC is a software company headquartered in Charlotte, North Carolina. Contact: requests@C2Consultants.net, or the form at https://www.c2consultants.net/contact/. A person replies within one business day. Machine-readable description of what we offer and how a request is made: https://www.c2consultants.net/.well-known/c2consultants.json. Notes for agents and other programs: https://www.c2consultants.net/for-agents/. ## Products ### C2Empowered (https://www.c2consultants.net/products/c2empowered/) The operations platform, built on IntentSharp. Self-hosted on the customer's own servers. In Workflow Studio, the co-author drafts a workflow from a plain-language description; nothing runs or sends until it is validated and approved. Steps that send email, write to a system of record or act in an application stop for a named approver; the step's risk level decides. Standing approvals are granted deliberately by an administrator. Every run leaves a trace tied to the exact published version; published versions are kept, hashed and comparable. Fleet Agents are lean installs that enroll with the main installation and run its workflows on other machines; each Fleet Agent runs one workflow at a time today. It reaches Windows applications through Microsoft UI Automation (Windows applications only, not mainframe screens or Citrix sessions, and it needs a signed-in Windows desktop), web portals through browser scripts, SQL Server and ODBC, email, files, PDFs and spreadsheets, and approval-gated scripting. AI runs only in steps marked as AI steps; a local model runs by default, and which model runs, and where, is configuration the administrator sets for every use (local models through Ollama, or hosted models from OpenAI or Anthropic). No telemetry; the licence is verified on the customer's own server, offline. Releases are signed and verified before install. 112 workflow node types across 32 business modules; 7,384 automated tests passing at the last full run. Proof, labelled: a government portal filing in production takes 112 s automated (Measured, median of the last 18 runs) against 10–20 min by hand (the customer's estimate), about 100 filings a week. AI triage of work items takes about 7 s per item (Measured AI). Measured from the install's own run traces, not a lab benchmark. How it is sold: a pilot first, then a perpetual licence sized to the organization, quoted at the results review. Unlimited users, workflows and runs. An annual update and support plan keeps the customer on current releases; the installed version keeps running if it lapses. ### IntentSharp (https://www.c2consultants.net/products/intentsharp/ · https://intentsharp.com/) A .NET library. Developers express application behavior as intent on ordinary .NET values and methods; intent, data shapes and rules live in versioned JSON or YAML files. Every model answer is checked against the .NET type and the rules, and retried with the findings when it fails them, within set limits; every attempt is kept. A pass means the checks passed, not that the answer is right. Runs on .NET 8, 9 and 10; works with OpenAI, Anthropic or any Microsoft.Extensions.AI IChatClient, including a local model on Ollama. Three NuGet packages, one version: IntentSharp, IntentSharp.Catalog, IntentSharp.Extensions.AI. 1.0 on NuGet (https://www.nuget.org/packages/IntentSharp). Commercial, not open source. From $349 per developer per year, unlimited deployments; free 30-day evaluation on development and test systems. Our estimate for a typical business application is 20 to 40% less C# code (an estimate, not a measurement). ### Binary Intelligence (https://www.c2consultants.net/products/binary-intelligence/ · https://binaryintelligence.ai) Self-healing Windows fleets. It keeps a live model of the fleet's state, diagnoses deviation, applies bounded remediation inside operator-defined boundaries and validates the fix before standing down. Design-partner stage. Sold direct, annually; cloud, on-prem or hybrid. ## The pilot A pilot puts C2Empowered on the customer's own server and proves it on one of their processes. Installation: $1,750 fixed fee. Discovery (document the process and establish the cost baseline): $2,000 fixed fee. Workflow build: $175 per hour, as billed. Six steps: discovery; the customer's written sign-off on the selected process; installation; build and test; go-live side by side with the current process; results review against the discovery baseline. Savings are measured, not estimated: hours × people × rate, before and after. To start, bring a process your team repeats, who does it and how long it takes, and sample documents. Scope one at https://www.c2consultants.net/contact/?topic=c2empowered-pilot. ## The method Cognitive Infrastructure, our method, asks four questions of every capability, at every scale: what does it mean, what does it require, who may use it, and what happened when it ran. IntentSharp applies it inside a program; C2Empowered applies it across an organization's work; Binary Intelligence applies it to the Windows estate. Between organizations, websites that other companies' software can use are the direction, not yet a product. # Writing: "Managing AI that does the work" The full text of every published paper in the series, in order. Figures are given as their captions and text descriptions. ## Managing AI that does the work Source: https://www.c2consultants.net/writing/series-overview/ Subtitle: A series on moving people from doing the work to governing it Published: 2026-11-01 ### The abstract the series exists to prove Organizations are adopting AI faster than they can govern it. The result in most firms is forty people in forty chat windows, data pasted into browsers, and no record of any of it, beside a written policy nobody can enforce. Our thesis is that the fix is not a better model and not a stricter memo. It is software that can be **told what to do, held to what it may do, and made to account for what it did**. When software has those three properties, a person can state an outcome, grant bounded authority, and follow the result. The work still gets done. The people stop being the ones typing it, and start being the ones who approve it and answer for it. The series shows how an organization gets there, one question at a time. Each paper is a chapter: it takes one question a buyer actually asks, answers it from the thesis, shows what it looks like in a firm like theirs, and ends with what to do first. Read in order they build the argument; read alone each one stands. ### The through-line, in four questions Every chapter answers the same four questions about a capability, because that is the method under every C2 product: | Question | What it means for a leader | Where the series answers it | |---|---|---| | What does it mean? | The work is described in business terms people and software both read | Chapters 4 and 5 | | What does it require? | Its inputs, rules and systems are declared before it runs | Chapters 3 and 5 | | Who may use it? | Authority is explicit, bounded and recorded; a refusal is a valid outcome | Chapters 1 and 2 | | What happened when it ran? | A record an auditor can be shown: this version, this run, this approver | Chapters 1, 2 and 3 | ### The chapters | # | Title | Reader | The question it answers | Figures | |---|---|---|---|---| | 1 | Every organization has an AI policy. Almost none has a way to make people follow it. | CEO, managing partner | Why does our policy not work, and what would? | Forty windows vs one governed place; policy as document vs governance as mechanism | | 2 | Authority must remain explicit | Compliance, risk, head of IT | How can AI act in our operations without acting on its own authority? | Interpretation vs permission matrix; the approval gate in a run; what the record holds | | 3 | Pay for AI when the work is designed, not every time it runs | CFO and CTO | Why do AI bills grow with volume, and how do we stop that? | Cost against volume: per-call vs designed-once (illustrative); where the model is called; the measured filing (112 s against 10–20 min) | | 4 | The cost of repeated translation | COO, CFO | Where does the time actually go? | The hand-offs in one process, each a translation; the same process with meaning kept outside code | | 5 | Typed, checked AI calls for .NET | .NET architects | How do we put a model in a business application without breaking the pipeline? | The checked call: intent, shape, rules, retry with findings, typed result; what changes with a save vs a release | | 6 | A Tuesday, before and after | Operations leaders | What changes for the people who do the work? | The filing clerk's day as a timeline, before and after; the supervisor's queue | | 7 | Websites other software can use | Founders, product leaders | Where does this lead between organizations? | The purchasing request across two companies' governed interfaces | ## Every organization has an AI policy. Almost none has a way to make people follow it. Source: https://www.c2consultants.net/writing/every-organization-has-an-ai-policy/ Subtitle: Chapter 1 of Managing AI that does the work For: CEO or managing partner of a mid-sized firm Published: 2026-11-02 ### Where this chapter sits The series argues that the way to adopt AI without losing control is software that can be told what to do, held to what it may do, and made to account for what it did. This chapter is the starting point: the gap every leader already feels between the AI policy the firm wrote and the way AI is actually used. The chapters that follow take the gap apart one question at a time: who may act, what it costs, where the time goes, and how a developer puts a model into an application safely. ### The problem, as you would put it Sometime in the last two years your firm wrote an AI policy. It probably says sensible things. Do not paste client information into public tools. Check what the tool gives you before you rely on it. Use the approved service, not whatever you found last night. Someone in IT or compliance drafted it, the leadership team read it, and it went out to everyone with a request to acknowledge it. Now ask a harder question. If a client, a regulator or your own board asked tomorrow how AI was used on a particular piece of work last month, could you answer? In most firms the honest answer is no. Not because people ignored the policy on purpose, but because the work happened somewhere the policy cannot see. Forty people have forty chat windows. Each person has their own way of asking, their own saved prompts, their own sense of what counts as checking the answer. Some use the approved service. Some use a personal account because it was quicker. None of it leaves a record that anyone else can read. Figure 1. Forty windows and no record, against one governed place. The policy is the same in both pictures. Only the right one can show what happened. (Figure, described: Left: many small chat windows, each sending data to an unknown destination, with no record. Right: one governed place where work is defined, approved and recorded, with a ledger of runs.) You have a document that describes how AI should be used. You do not have a way of knowing how it is used. That gap is where the questions you dread live: which model produced this, who reviewed it, what client information went into it, and why two people doing the same task got two different results. This is not a failure of discipline. It is a failure of design. A policy tells people what to do. Nothing in the firm makes it easy, or even possible, to do it the same way every time. ### Why the usual fixes do not close the gap The first fix most firms reach for is a better policy. The document gets longer, more specific and more carefully worded. It does not help, because the problem was never the wording. A clearer rule that still lives in a PDF is still a rule nobody can check. The second fix is training. Everyone sits through a session on responsible use. People leave better informed and then return to the same private windows with the same habits. Training changes what people know. It does not change where the work happens or whether anyone can see it afterwards. The third fix is to approve a single tool and block the rest. This is closer, because it at least narrows where the work goes. But an approved chat tool is still a blank box. It records conversations, not work. It cannot tell you that a given output was produced by an agreed method, checked against agreed rules and approved by a named person before it went to a client. Two people using the same approved tool can still do the same task in two different ways. The fourth fix is to ban AI outright. In a regulated firm this can feel like the safe choice. In practice it moves the use into personal devices and personal accounts, where the firm has even less visibility than before. Each of these treats AI use as a matter of individual behaviour. The underlying issue is that the firm has no shared place where the work itself is defined. ### The idea: a policy is a document, governance is a mechanism There is a difference between saying how work should be done and having a mechanism that does it that way. A policy is the first. Governance is the second. Figure 2. The same rule, stated as a policy and built as a mechanism. The last row is the one a regulator will ask about. (Figure, described: A two-column comparison. Policy: the rule lives in a PDF, is checked never or after the fact, leaves a signed acknowledgement, and when ignored nothing happens. Governance: the rule lives in the route the work takes, is checked every run, leaves a record per run, and when the rule is not met the step stops.) Our thesis puts the ownership question plainly: "The organization should decide which information each model receives and what its outputs may influence." (C2Consultants, *Intelligent Software and Autonomous Organizations*.) A memo cannot make that decision stick. Only a system can, because only a system sits between the person and the model every time. That system has three jobs. First, it is where AI work is defined: what the task is, what information it may use, which model it calls and where that model runs. Second, it is where that work is approved: the steps that send, write to a system of record or act in an application stop for a named person before anything goes out. Third, it is where the work is recorded: what was asked, which version of the definition governed it, and what happened when it ran. Figure 3. The three jobs of the one place. The policy stops being a request and becomes the default route the work takes. (Figure, described: A left-to-right flow. A request enters a defined task; routine steps run; a step that sends, writes or acts stops at an approval gate for a named person; after approval the run completes and a record is kept of the version, the run, the approver and the data seen.) When those three jobs live in one place, the policy stops being a request and becomes the default. People do not have to remember the rules, because the rules are built into the only route the work can take. A person who wants a client summary does not open a blank window and improvise. They run the agreed summary, which already knows what it may read, which model it uses and who must approve it. The thesis describes the result as a change in what a request is: "A request becomes a durable task with a purpose, relevant context, permitted actions and an accountable state." (C2Consultants, *Intelligent Software and Autonomous Organizations*.) That sentence is the whole difference between a chat window and governed work. A chat ends when the window closes. A durable task keeps its history, its permissions and its outcome where others can see them. There is one more benefit, and it is the one leaders tend to undervalue. When the same task runs the same way for everyone, it becomes consistent. The quality of the work no longer depends on which person happened to write the prompt. That is the real meaning of making people follow the policy: not watching them more closely, but giving them one good way to do the work and making it the easiest way. ### What it looks like in a firm like yours Consider a mid-sized firm of around two hundred people in a regulated sector. Its staff use AI informally for three recurring jobs: summarising long incoming documents, drafting first-pass replies to routine client questions, and preparing the paperwork for a government portal filing. Today each of those happens in someone's chat window. The summaries vary in length and focus. The draft replies sometimes include details that should not have left the building. The filing preparation depends on one experienced person who knows which fields matter. Under a governed approach the firm defines each of the three jobs once. The document summary has a stated purpose, a fixed set of sources it may read, and a model the administrator chose. Administrators can choose local models for every use, so a sensitive job can run on the firm's own hardware. The draft reply runs the same way, but it stops at an approval gate before anything is sent, and a named reviewer sees the draft, approves or rejects it, and that decision is recorded against the run. The filing preparation follows the same steps for every filing, and the trace shows what was entered and who signed off. Nothing about the policy changed. What changed is that the policy is now the route the work takes. When the board asks how AI was used on last month's client correspondence, the answer is a record, not a guess. ### What to do first, before you buy anything **1. Find out where AI is already being used.** Ask each team, without blame, which tasks they use AI for and which tools they use. You will likely find a short list of recurring jobs that account for most of it. That list is your real AI footprint, and it is almost certainly different from the one your policy assumes. **2. Pick one recurring task and write it down as work, not as a rule.** Choose a task that happens often and carries some risk. Write what it is for, what information it may use, what a good result looks like, and who must approve it before it leaves the firm. This single page is the start of governance. It will also show you how much of your current policy is guidance nobody can act on. **3. Decide who answers for each step that has consequences.** For that one task, name the person who approves the output and the person who owns the definition when it needs to change. If you cannot name them, the policy has no owner in practice, and that is the first thing to fix. These steps cost nothing but time. They will tell you whether the gap in your firm is small or large, and they give you a concrete starting point whatever you decide next. ### How C2Consultants does this C2Empowered is the operations platform we build for exactly this gap: one place where AI work is defined, approved and recorded, instead of forty people with forty chat windows and no record. Each workflow is a published, versioned definition; the steps that send, write to a system of record or act in an application stop at approval gates set by risk level for a named approver; every run keeps a step-by-step trace tied to the version that governed it; and administrators choose which model each task uses and where it runs, including on the firm's own hardware. One honest limit: it governs the work that runs through it, so it does not reach a personal chat account someone opens on their own phone, and it works only as well as the definitions your people agree to write. In one line, C2Empowered takes AI and makes it consistent. The way to start is a pilot: discovery of your recurring AI work ($2,000), installation ($1,750), and building and testing your first workflows ($175 per hour), run side by side with how you work today before you decide anything more. *Next chapter: Authority must remain explicit. How AI can act in your operations without acting on its own authority.* ## Authority must remain explicit. How AI can act in your operations without acting on its own authority. Source: https://www.c2consultants.net/writing/authority-must-remain-explicit/ Subtitle: Chapter 2 of Managing AI that does the work For: Compliance officers, risk officers and heads of IT in regulated mid-sized firms Published: 2026-11-02 ### Where this chapter sits Chapter 1 argued that an AI policy becomes real only when there is one place where AI work is defined, approved and recorded. This chapter takes the middle job, approval, and asks the question a compliance officer has to answer: when a model is part of the work, who actually authorized what it did? The answer turns on one distinction the rest of the series depends on, between a model understanding a request and anyone having permitted it to act. ### The question your auditor will ask Somewhere in your firm a model is already doing part of the work. It summarizes incoming requests, sorts a queue, drafts replies, or fills in a form that someone then submits. It arrived because a team wanted to save time, and it probably does. Now picture the audit. The reviewer picks one record that left the building last quarter: a letter to a third party, a filing, a change to a client account. The questions are simple. Who decided this should go out? What were they looking at when they decided? Which rules applied, and were they the rules in force that day? Can you show that what was approved is what was sent? For work done by people you can usually answer. There is a sign-off, a ticket, an email chain, a name. For work a model touched, the honest answer in many firms is some version of "the system did it." The model read the request, worked out what was wanted, and the next step happened. Nobody granted that step. It followed from the model's understanding. That gap is not about accuracy. A perfectly accurate model still leaves you without an answer to "who authorized this," because accuracy and authority are different things. A regulator, a client or a court will not accept "the model decided" as an explanation. They will accept a record that says this version of this process ran on these inputs, produced this output, and this named person approved it. If you own compliance, risk or IT, you are the person who will be asked for that record. ### Why the usual fixes fall short The first fix is the policy that says staff must review AI output before relying on it. It is sincere, but it is a document, not a mechanism. It cannot tell you whether review happened on a given record, who did it, or what they saw. The second fix is a better model or a more careful prompt. That improves the interpretation and does nothing for the authority. A model that understands a request more precisely is still not the person who may approve it. The third fix is to keep a reviewer somewhere in the chain. That helps only if the review is attached to the specific action it permits. Someone who glances at a dashboard each morning is not the same as a named approver whose decision is recorded against the exact run that produced the exact output. Without that link, review is a habit you cannot prove. The fourth fix is to log everything. Logs are necessary, but a log of model calls tells you what the model said. It does not tell you what the organization permitted, under which limits, or why the next step was allowed to proceed. Each of these treats authority as something that follows from good output. It does not. It has to be granted, bounded and written down. ### The idea: understanding is not permission Our thesis states the point in one sentence: "Understanding an action and having permission to perform it are separate properties." (C2Consultants, *Intelligent Software and Autonomous Organizations*.) A model may interpret a request, propose a plan or notice a likely exception. None of that creates authority. The organization decides who may authorize a piece of work and the limits within which it may proceed. Once the two are separated, every situation falls into one of four cells, and only one of them lets the work go ahead. Figure 1. Understanding and permission are separate questions. The red cell is the one most AI deployments quietly treat as the top-left: the model understood, so the step ran. (Figure, described: A two-by-two matrix. Columns: the software understands the request, or does not. Rows: the action is permitted, or not. Understands and permitted: it acts, within the mandate, and the step is recorded. Does not understand but permitted: it stops and asks a person. Understands but not permitted, highlighted in red: it stops and refuses, because understanding grants nothing. Does not understand and not permitted: it cannot proceed.) Three consequences follow, and each maps to something an auditor can check. First, authority should be explicit and bounded. Rather than letting a process act wherever its interpretation leads, you grant it a mandate: these systems, these recipients, these amounts, this period. Routine work inside the mandate continues. Anything consequential, or anything outside the limits, waits for a person with the standing to decide. Autonomy grows by widening the mandate deliberately, not by trusting the model a little more each month. Second, stopping is a legitimate result. The thesis is direct: "A refusal or an unresolved ambiguity is a valid operational outcome when the conditions for proceeding have not been met." (C2Consultants, *Intelligent Software and Autonomous Organizations*.) A process that halts because an approval is missing, or because a request is ambiguous, has worked correctly. In regulated work an honest stop is far cheaper than a confident wrong action, so a stop should be a normal, recorded outcome rather than an error someone engineers away. Third, the record has to survive. The organization keeps what was requested, which definitions and permissions governed the action, and the evidence of what happened. An interrupted task keeps its history. Stopping future work leaves completed effects visible, so people can reconcile what was done before anyone tries again. For heads of IT this extends past the server room: who can delegate work, which systems an execution identity may reach, and how a completed action is explained should all have named owners inside the firm, and survive a change of model provider. ### What it looks like in a firm like yours Consider a mid-sized healthcare administration firm that receives requests to release records to third parties. Today staff read each request, check it against the firm's release rules, pull the records, draft a cover letter and send the package. It is slow, repetitive, and exactly the kind of work a model can help with. In the version that worries an auditor, a model reads each request, decides it is valid, and the sending step runs. Most of the time the decision is right. When it is wrong, nobody can say who allowed it. In the version built on explicit authority, the work is a defined process with a published, versioned definition. A model reads the incoming request and proposes a classification: which rule applies, which records are involved, what is missing. That proposal is interpretation, and it is labelled as such. Exact checks, such as whether a signed authorization is on file, run as exact steps, not as model judgments. Figure 2. The approval gate inside a run. Nothing goes out until a named person approves, and the decision is kept against that same run, not in a separate inbox. (Figure, described: The same four-step flow as chapter 1: define, routine steps, approve, record. Under the approve step hangs the approval card: risk level 3, a named approver, what the approver sees (the draft, the request and the evidence), and two buttons, approve and reject. Approve lets the run continue; reject stops it and the stop is recorded. Under the record step hangs the entry the gate leaves: the version, the run, the approver, the time and the data seen.) The process then reaches an approval gate. The draft package sits there, visible, with the request and the supporting evidence beside it. A named person, chosen because they hold the authority for that kind of release, approves or rejects it. Nothing goes out until they do. Gates are set by risk level: the steps that send, write to a system of record or act in an application stop for a named approver, and the routine reading and checking before them does not. If the request is ambiguous, or the authorization is missing, the process stops and says why. That stop is recorded like any other outcome, and the person who picks it up sees what was asked, what the model proposed and what was missing. Figure 3. What the record holds. Each column answers one of the auditor's questions; the highlighted one is the answer "the model decided" can never give. (Figure, described: One ledger row with five columns: version, run, approver, time and data seen, with an example entry for a records release. Under each column is the audit question that part answers: which rules applied, what happened, who decided, when, and what they were looking at. The approver column is highlighted.) At audit the reviewer picks a record. The firm can show the version of the process that ran, the inputs it received, each step it took, the output it produced, and the approval recorded by name against that same run. "The model decided" never appears. "This version, this run, this approver" does. ### What to do first, before you buy anything **1. List every place a model's output can leave without a named approval.** Include every route by which an output can reach a client, a counterparty, a regulator or a system of record without a named person approving that specific action, informal uses included. Most firms find more than they expected. **2. Write one mandate down.** For one of those places, write who may approve this kind of action, within what limits of amount, recipient and time, and what should make the work stop instead of proceed. If it does not fit on a page, the authority is not yet explicit. **3. Run the audit question as a drill.** Pick one AI-assisted output from last month and try to answer it in full: which version of the process, which inputs, which rules, which approver. Time how long it takes and note where the trail breaks. That break is your first piece of work. These steps cost nothing but time, and they tell you how far your firm is from being able to answer the question before someone else asks it. ### How C2Consultants does this C2Empowered is the operations platform we build for this problem, and it applies Cognitive Infrastructure, our method, to it: every workflow is a published, versioned definition that cannot change under a run; the steps that send, write to a system of record or act in an application stop at approval gates set by risk level for a named approver; the approval is recorded against a completed run of that same workflow; every run keeps a step-by-step trace; and administrators choose which model each task uses and where it runs, including local models for every use. One honest limit: software cannot pass an audit for you. Auditors assess your deployment and your practices, and the most we claim is that C2Empowered produces the record as a by-product of doing the work, for the work that runs through it. The way to start is a pilot: discovery ($2,000), installation ($1,750), and one of your own workflows built and tested ($175 per hour), run side by side with how you work today, followed by a results review. *Next chapter: Pay for AI when the work is designed, not every time it runs. Why AI bills grow with volume, and how to stop that.* ## Pay for AI when the work is designed, not every time it runs Source: https://www.c2consultants.net/writing/pay-for-ai-when-the-work-is-designed/ Subtitle: Chapter 3 of Managing AI that does the work For: CFO and CTO of a mid-sized firm, reading together Published: 2026-11-02 ### Where this chapter sits The series argues that the way to adopt AI without losing control is software that can be told what to do, held to what it may do, and made to account for what it did. Chapter 1 described the gap between an AI policy and the way AI is used. Chapter 2 asked who may act. This chapter asks the question finance and technology bring to the table together: why the AI bill grows with the business, and why the same design that stops that growth is also the one that lets you prove what happened. ### The problem, as you would put it The pilot went well. Someone connected a language model to a queue of invoices, claims or intake forms, and the model read each one, pulled out the fields and passed them on. It was faster than doing it by hand, and the demonstration was convincing. Then the invoice for the model arrived, and it had the same shape as the work. More volume meant a bigger bill, and a busy quarter meant a bigger one still. The CFO now has a cost line that grows with the business itself, priced by a vendor who can change the rate. The CTO has a different worry, and it is the more serious one. An auditor, a customer or a regulator asks why a particular record was handled the way it was. The honest answer is that the model read it that way on that day. Run the same record again and the answer may differ. There is no version to point to, no rule to show, and no way to prove which answer was the one that went out. So the two of you are looking at one decision from two sides. One side asks what it costs. The other asks whether it can be defended. Both questions have the same cause. Figure 1. Cost against volume (Illustrative). One cost follows the number of records; the other follows the number of distinct sources and how often they change. The chart shows the shape, not a measured saving. (Figure, described: An illustrative chart with no numeric values. The horizontal axis is records processed and the vertical axis is AI cost. One line, a model call on every record, rises steadily as records increase. The other line, the model called when the work is designed, stays flat after an initial step for the design, with two small further steps where a source changes shape.) ### Why the usual fixes do not close the gap The first fix most firms reach for is a cheaper model. That lowers the rate, but the cost still rises with every record, and a smaller model reads less reliably, so more records need a person to check them. The line on the budget is still a rising line; it is just a shallower one. The second fix is to negotiate volume pricing or a fixed-fee plan. That moves the risk around without removing it. The vendor prices in your growth, and the reproducibility problem is untouched. The third fix is to add review. A person checks a sample of what the model produced. That catches some errors, but it brings back the labor the automation was meant to remove, and a sample is not a record. When someone asks about one specific case, a sampling policy does not answer the question. The fourth fix is to write better prompts. A prompt is still an instruction to something that interprets. It narrows the range of answers; it does not make the same input produce the same output every time. All four accept the starting assumption that the model must run on every record, forever. That assumption is the cause of both problems. ### The idea: use the model to design the work, then let the work run without it Most of what a model does in a per-record pipeline is not judgment. It is translation. A supplier calls a field one thing, the accounting system calls it another, and the model is paid every time to notice that they mean the same thing. The meaning did not change between yesterday's invoice and today's. Only the data did. Our thesis makes the point directly: "A recurring transformation should be able to run through a validated artifact." (C2Consultants, *Intelligent Software and Autonomous Organizations*.) In plain terms, if the same translation happens every day, work it out once, check it, keep it as a definition people can read, and run that definition from then on. That changes when the model is called. It is called once to draft the process. It is called once to write a script, or to map a new source's layout onto the layout the firm already uses. It is called again only when the source changes shape, such as when a supplier redesigns its invoice or a portal adds a field. It is not called because the data changed. Everything between those moments is a deterministic step: the same input produces the same output, every run. The engineer's version is short. The model writes the pipeline. The pipeline runs without it. Figure 2. Where the model is called. It works at design time and when a source changes shape; it is not called because the data changed. (Figure, described: A timeline of one workflow over time. The model is called at three marks: first at design, where it drafts the workflow and a person approves it; then a source changes shape, the run stops and reports; then the workflow is designed again and a new version is approved while the old one is kept. Between the marks, many runs happen as deterministic steps with no model call.) None of this means the model disappears. Some work genuinely calls for interpretation every time: reading a free-text complaint, sorting an unusual request, judging a case that fits no rule. The thesis is careful about this too: "When a case genuinely requires interpretation, a bounded model call can address that uncertainty." (C2Consultants, *Intelligent Software and Autonomous Organizations*.) The point is to pay for judgment where judgment is the job, and to stop paying for translation that was already solved. For the CFO, the result is a different cost curve. Model spend follows the number of distinct sources and the number of times they change, not the number of records. A busy quarter is a busy quarter for the deterministic steps, which cost the same per run as a quiet one. For the CTO, the result matters more. Because the steps are deterministic, the answer to "why was this record handled this way" is no longer "the model decided". It is this process, this published version, this run, these inputs, this output, and this named person who approved it. That is an answer an auditor can check. The cost saving is the commercial argument; the ability to prove what happened is the one that gets a reviewer to say yes. We do not publish a ratio for the saving. It depends on how much of a process is translation and how often its sources change, and a number we have not measured for your work would be a number you could not rely on. The mechanism is what we stand behind. ### What it looks like in a firm like yours Take a mid-sized firm that receives supplier invoices in many different layouts and keys them into its accounting system. Part of the finance team spends some of every day on it. In the per-call design, every invoice goes to a model, which reads it and returns fields. The cost rises with every invoice, and nobody can say for certain how a particular invoice was read last March. In the designed version, the model is used up front. It reads examples from each supplier and proposes a mapping from that supplier's layout to the firm's own fields. A person reviews each mapping, the way they would review a new procedure, and approves it. From then on, each invoice runs through the approved mapping without a model call, and totals are calculated by exact arithmetic, not estimated. When a supplier changes its invoice, the step that expects the old layout fails, so the run stops and reports instead of guessing. The model proposes an updated mapping, a person approves it, and it becomes the next version. The old version is kept, so last March's invoices can still be explained by the rules in force last March. Any invoice that fits no known layout goes in front of a person, and anything consequential, such as releasing a payment, waits at an approval step with the named approver recorded. The same pattern applies to filing work. In one case we measured, a government portal filing took 112 seconds automated (Measured: the median of the last 18 runs), against 10 to 20 minutes by hand (the customer's estimate), at about 100 filings a week. The filing runs as a published workflow whose steps are the same every time; the time saved comes from the work being designed, not from a model reading every form. Figure 3. The measured filing. The only production number in the series, with its label: 112 s automated (Measured, median of the last 18 runs) against 10 to 20 minutes by hand (the customer's estimate). (Figure, described: Two horizontal bars drawn to the same scale, per filing. By hand: 10 to 20 minutes, the customer's estimate, shown as a solid bar to 10 minutes with a lighter extension to 20 minutes. Automated: 112 seconds, measured as the median of the last 18 runs, a much shorter bar. About 100 filings a week.) ### What to do first, before you buy anything **1. Find where the model is called.** For each process that uses a language model today, write down whether the model runs once per record or once per design. Most firms find the answer is once per record, everywhere. **2. Separate judgment from translation.** For each of those processes, ask whether the model is deciding something that genuinely varies case by case, or recognizing the same fields in the same layouts again. Mark each step one or the other. The translation steps are the ones that can stop costing money on every run. **3. Run the reproducibility test.** Pick one record handled last quarter and ask the owner of the process to show exactly why it was handled that way, and to produce the same result again today. If they cannot, that is the risk your auditors will find, and it is worth knowing before they do. ### How C2Consultants does this C2Empowered, the operations platform we build, applies this approach. In Workflow Studio the co-author uses a model to draft a workflow from a plain description and to map a new source onto the layout you already use; once a person approves and publishes it, Fleet Agents run that published version step by step without calling a model for the translation, and the model is called again when a source changes shape. Administrators choose local or hosted models for every use. Each run keeps a trace tied to the version that governed it, and each consequential step waits at an approval gate set by risk level for a named approver, so the record of what happened is produced by doing the work. One honest limit: this pays off where the work repeats; a step that genuinely needs judgment on every item still calls a model every time, and its cost still rises with volume. The way to find out how much of your work is translation is a pilot on one of your own processes: discovery ($2,000), installation ($1,750), and building and testing your first workflows ($175 per hour), run side by side with how you work today before you decide anything more. *Next chapter: The cost of repeated translation. Where the time in a process actually goes.* ## The cost of repeated translation Source: https://www.c2consultants.net/writing/cost-of-repeated-translation/ Subtitle: Chapter 4 of Managing AI that does the work For: COO or CFO of a mid-sized firm in a regulated or paper-heavy sector Published: 2026-11-02 ### Where this chapter sits The first three chapters were about control: where AI work is defined, who may let it act, and when the firm pays for a model. This chapter steps back to the reason most of that work exists at all. A large share of what operations teams do every day is carrying information from one place to another and changing its form on the way. That is translation, and it is the cost the rest of the series is trying to remove. The next chapter goes inside a single program, where a developer does the same translation in code. ### The problem, as you would put it Ask an operations team where their week goes and you will rarely hear the word "translation". You will hear "re-keying", "chasing", "checking it matches", "fixing the spreadsheet", "sending it back because the number was in the wrong column". Those are all the same activity. Information leaves one place in one form and has to arrive somewhere else in another, and a person stands in the middle doing the conversion. Follow one routine piece of work from start to finish. A request arrives by email. Someone reads it and types the useful parts into a spreadsheet. Someone else takes the spreadsheet and copies its values into a portal. A third person downloads what the portal returns and files it. Four systems, three people, six hand-offs, and at every one of them the meaning of the work is carried across by hand. Figure 1. One process, six translations. Every arrow is a person converting information from one form into another, and none of them leaves a record of the rule they used. (Figure, described: A zigzag flow. Along the top, four systems: email, spreadsheet, portal and file. Along the bottom, three people, one between each pair of systems. Six arrows run from system to person to system, and each arrow is marked translation. A note says which rule each person applied is not recorded.) Each of those hand-offs costs time. Few firms measure it, because it never appears as a line item. It is spread across salaries, overtime, the senior person who is the only one who knows how a particular report is assembled, and the correction that turns up a month later. In a regulated or paper-heavy firm, a large share of administrative cost is probably this work, and nobody has ever added it up. The second cost is quieter and more expensive. Every translation is a chance to lose meaning. A date is read the wrong way round. An amount in cents is read as dollars because the field kept the same name. A rule that applied last quarter is applied again after it changed. The person doing the conversion is careful, but careful is not the same as checked, and nobody can see afterwards which version of the rule they used. ### Why the usual fixes do not remove the cost Firms usually try one of three things. The first is more people, or better-trained people. That works until volume rises, someone leaves or the rules change. It also keeps the knowledge in heads rather than anywhere the firm can inspect. When the experienced coordinator is on holiday, the work slows down or the errors go up. The second is a custom integration. A developer writes code that maps one system's fields to another's. This removes the re-keying for a while. The trouble is that the meaning now lives inside compiled code that only the developer can read. When a supplier changes a document or a department revises a rule, the business need is unchanged but the code must be rewritten. The translation has not gone away. It has moved somewhere harder to see and more expensive to change. The third is to put an AI model on the problem. A model reads each incoming document and produces the output you want. This can look like the end of translation. In practice it repeats the translation on every record, for as long as the work runs. The cost rises with volume, and the same input can produce a different answer on a different day. In a regulated filing, "the model decided" is not an answer an auditor accepts. You need to be able to say which version of the work ran, on which inputs, and who approved it. All three share a flaw. None of them gives the meaning of the work a home of its own, separate from the people and the code that carry it out. ### The idea: give meaning a home outside the code Our thesis starts its economic argument here, with the translation a firm already pays for: developers turning business meaning into application code, employees carrying information between applications, and businesses exchanging requests and records across their boundaries. "Each repetition consumes effort and creates another place where meaning can be lost." (C2Consultants, *Intelligent Software and Autonomous Organizations*.) The remedy is to keep the meaning in definitions that sit outside the code: what a field means, what units it is in, which rules apply, which substitutions are allowed. People can read those definitions. Software can execute against them. When a definition changes, it changes in one place, the change can be reviewed, and the firm can see when it took effect. Figure 2. The same process with the meaning kept in one definition. The arrows now carry data rather than re-typing, and people spend their time where a decision is needed. (Figure, described: One definition box at the top holds what each field means, its units, the rules that apply and its version; it is read by the people who own it and executed by the software on every run. Below, the same systems, email, spreadsheet, portal and file, are joined by arrows that carry data, not re-typing. Dashed lines show the definition applied at each hand-off. Before the portal, an approval step waits for a named person.) This does not make the work less exact. Arithmetic, transaction rules and permission checks keep exact implementations. Interpretation is reserved for the cases that genuinely need it, such as an ambiguous description on an incoming document, and even then it is bounded and checked. Recurring conversions run through a definition that has been reviewed and adopted, not through fresh guesswork on each record. That is also why the model, where one is used, is called when the definition is written or when a source changes shape, rather than on every record, as chapter 3 set out. Nor does it remove responsibility. The thesis is direct about this: "Moving a rule outside a compiled method does not remove the responsibility to define it correctly." (C2Consultants, *Intelligent Software and Autonomous Organizations*.) What it creates is a place where the rule can be inspected, revised and tied to the conditions under which it is valid. That is what your auditor, your controller and your next hire all need. The second half of the idea is about who does what. Software carries the routine coordination: moving the information, applying the definitions, noticing what is missing. People keep the authority: approving the consequential step, deciding the exception, owning the outcome. The record of what happened belongs to the firm, not to a conversation window or a model provider. The same pattern holds at every scale where translation happens. Inside a program, developers translate business rules into code. Between applications, employees carry values from one screen to the next. Between companies, a supplier's document and a regulator's form each expect their own fields. The question is the same each time: what does this value mean, and who decided? Figure 3. Translation happens at three scales. The rest of this series takes them one at a time: the program in chapter 5, the organization's own operations throughout, and the exchange between companies in chapter 7. (Figure, described: Three nested boxes. The innermost is inside a program, where developers translate business rules into models, mappings and validation code. Around it is between applications, where employees carry values from one application to the next, such as customer_number in one and account_id in another. The outermost is between companies, where suppliers, clients and regulators each expect their own documents and fields. A line at the bottom states the same question applies at every scale.) ### What it looks like in a firm like yours Take a mid-sized firm that submits a recurring government portal filing for each of its sites or clients. Today the work goes like this. Data arrives from two internal systems and a spreadsheet kept by the field team. A coordinator copies each value into the portal, checks it against last period, fixes the mismatches and files. When the portal changes a field, someone notices by getting an error. With the meaning kept in definitions, the same work looks different. The fields the portal expects are written down once, along with which internal source supplies each one and what units it uses. The rules are written down too: which values must match last period, which records are out of season. A workflow reads the sources, applies the definitions, fills the portal, and stops at an approval step where a named person sees what is about to be submitted. Every run leaves a trace: which version of the workflow ran, on which inputs, who approved it, and what the portal returned. When the portal changes a field, the change is made to the definition, reviewed and published as a new version. The coordinator's job moves from typing every value to supervising many filings and handling the exceptions. On one installation of this kind the automated filing takes 112 seconds (Measured, median of the last 18 runs), against 10 to 20 minutes by hand (the customer's estimate), at about 100 filings a week. It is one measurement, not a promise. The point is less the minutes than where the remaining time goes: into decisions a person should make, rather than conversions a person should never have had to do. ### What to do first, before you buy anything **1. Count one hand-off.** Pick a single recurring task that crosses at least two systems. For two weeks, have the people who do it note each time they copy, re-key or reconcile a value, and roughly how long it takes. Most firms are surprised by the total, and more surprised by how often the same value is converted twice. **2. Write the definitions down.** For the fields that cross in that task, write a one-page glossary: the name in each system, what it means, its units or format, and the rule that governs it. Where two people give different answers, you have found a place where meaning is already being lost. **3. Name the authority.** For each step in the task, write down who may approve it and what they need to see before they do. Separate the steps that are routine coordination from the steps that carry consequence. That list is the boundary between what software can carry and what people must keep. At the end of those three steps you will have a measured cost, a set of definitions and a map of authority. That is most of the design work for any automation, whoever builds it. ### How C2Consultants does this C2Empowered is the operations platform we build for this work. In Workflow Studio, the co-author drafts a workflow from a plain description of the task; the field mappings and rules are kept as definitions you can read and version, rather than buried in code; Fleet Agents run the work across your existing applications, from email and spreadsheets to web portals, SQL Server and Windows desktop applications; and the steps that send, write to a system of record or act in an application stop at approval gates set by risk level for a named approver, with a trace of each run kept as the firm's own record. The model is used when the work is designed and again when a source changes shape, not on every record. One honest limit: driving an application through its own screens works for Windows applications only, not mainframe screens or Citrix sessions, and a definition is only as good as the agreement your people reach on what each field means. The way to start is a pilot: discovery of the hand-offs that cost you most ($2,000), installation ($1,750), and building and testing your first workflows ($175 per hour), run side by side with how you work today before you decide anything more. *Next chapter: Typed, checked AI calls for .NET. How a developer keeps the same translation out of application code and still trusts what a model returns.* ## Typed, checked AI calls for .NET Source: https://www.c2consultants.net/writing/typed-checked-ai-calls-for-dotnet/ Subtitle: Chapter 5 of Managing AI that does the work For: .NET architects and senior developers who build and maintain business applications Published: 2026-11-02 ### Where this chapter sits The first four chapters looked at the organization: where AI work is defined, who may act, what it costs and where the time goes. This chapter goes inside a single program. It is written for the architects and senior developers who build the .NET applications those organizations run on, and it asks the series' four questions at the smallest scale there is: what a model call means, what an acceptable answer requires, who may change the rules, and what happened when the call ran. ### The problem, as you would put it Every .NET team that has put a model into a business application remembers the first afternoon. You pick a provider, send a prompt with some text, and get back something that looks like what you asked for. The demo works. Someone asks for it in production. Then the ordinary failures arrive. The model returns a category that is not in your enum. It writes a date your parser rejects. It wraps the JSON in a friendly sentence. It sets a priority of "urgent-ish". On Tuesday the same input gives a different answer from Monday's, and nobody can say which one reached the database. None of this is exotic. It is what happens when a component with a probabilistic output sits inside a pipeline that expects exact types. The call itself was never the hard part. Knowing whether the answer can be trusted, and what to do when it cannot, is the hard part. There is a second, slower problem. The wording of the prompt, the list of allowed categories and the rules about what counts as a valid answer end up as string constants and `if` statements in compiled code. When the business changes a rule, the change waits for a release. When an auditor asks which rule was in force last month, the answer is somewhere in the commit history, if anyone can find it. ### Why the usual fixes do not hold The first fix most teams reach for is a better prompt. It helps, until the next unusual input. A prompt states what you want. It does not check what you got. The second fix is a hand-written loop: parse the answer, validate it, and if it fails, ask again. This works, and almost every team writes one. The trouble is that each team writes its own, often several times inside one application. Each copy has its own idea of how many attempts to allow, what to tell the model on the retry, and what to log. Most of them retry with the same prompt, so the model has no idea what it got wrong. Most of them keep only the final answer, so the failed attempts that would explain a bad result are gone. The third fix is to move the rules into configuration. That is the right instinct, but a loose settings file has no shape, no version and no check on load. A typo in a list of allowed values becomes a production incident rather than a refused edit. The fourth fix is to keep the model away from anything that matters: it drafts, and a person retypes the result into the real system. That is cautious, and it gives back most of what the model was meant to save. Each of these addresses one symptom. None of them gives the call a contract: a stated goal, a stated shape, stated rules, a bounded way to recover, and a record of what happened. ### The idea: keep the meaning outside the compiled code Our thesis starts from a plain observation. Much of business software exists to reconcile differences in representation, and developers keep rewriting code because the business changed its vocabulary, not its need. Its proposal is a separation: a stable execution core carries out exact operations, and external definitions describe the contracts, interpretation rules and domain decisions that change. That separation applies directly to a model call. The goal of the call, the shape of the answer and the rules an acceptable answer must meet are definitions. They belong in files that can be read, versioned and changed on purpose. The code that sends the call, checks the answer, retries and records the attempts is machinery, and it should be the same for every call in the application. Figure 1. The checked call. The retry tells the model what it got wrong, both attempts stay on record, and a pass means the checks passed, not that the answer is right. (Figure, described: A left-to-right flow. An intent and an input go to the model the team configured. The model's answer is checked against the .NET type and the rules. If every check passes, the code receives a typed .NET value. If a rule fails, the rule's message goes back to the model on the next attempt, within the limits the team set for attempts, timeouts and model calls. Below, a ledger shows that every attempt is kept: the first refused because a priority was not an allowed value, the second passing every check.) Put together, a call becomes a checked call (Figure 1). The application states the intent and passes the input. The model's answer is checked against the .NET type the team owns and against the rules beside the intent. When a rule fails, its message goes back to the model on the next attempt, so the retry carries the finding instead of repeating the question. A transient error at the provider can move the call to the next provider in a configured chain. All of it happens inside limits the team set: attempts, timeouts and model-call ceilings. Every attempt is kept, the failed ones included. Two properties of that picture matter most. The record is complete: a developer can see what the model returned each time and which rule refused it. And a pass means the checks passed. It does not mean the answer is right. The thesis draws the boundary that keeps this honest. Arithmetic, transaction rules and permission checks keep exact implementations, and the model is reserved for the part of a case that is genuinely uncertain: "When a case genuinely requires interpretation, a bounded model call can address that uncertainty." (C2Consultants, *Intelligent Software and Autonomous Organizations*.) A checked call is that sentence written as machinery: bounded by a type, rules and limits, and used only where interpretation is the job. ### What it looks like in a firm's application Take a mid-sized firm with an internal application that receives customer requests by email and turns each one into a ticket. Today a person reads every message, picks a category, sets a priority and copies the account details into the ticket form. The team wants a model to do the first pass. The ticket stays an ordinary .NET type the team owns, with its category, priority and account fields. The intent lives in a file: a sentence saying what the call is for, a few examples, the output requirements, and a description written for people rather than for the model. The rules sit beside it: the priority must be one of the allowed values, the account number must match a pattern, a numeric field must fall within a range. Six months later the business adds a category. Someone edits the intent file and saves it, and the next call uses the new wording with no release. If the edit does not load, the last good version stays in force while the application runs, and the problem is reported by file and line. Every file carries a version, so the team can activate a version and revert to an earlier one. Figure 2. What a save changes and what still needs a release. The wording and the rules move at the speed of the business; types and code still move at the speed of a release. (Figure, described: Two columns. Changes with a save: the intent's wording, examples and output requirements; the rules such as allowed values, patterns and ranges; the description written for people; which version is active, including reverting to an earlier one. Needs a release: a new .NET result type, a new named code check, and code that calls a new intent by name. Below, a band explains that a bad save does not load, the last good version stays in force while the application runs, and the problem is reported by file and line.) The thesis is careful about what this does not mean. "Moving a rule outside a compiled method does not remove the responsibility to define it correctly." (C2Consultants, *Intelligent Software and Autonomous Organizations*.) A rule in a file still has to be right. What the file adds is a place where the rule can be inspected, revised and tied to the period in which it was in force. The approach has edges, and they matter. A new .NET result type, a new named code check, or code that calls a new intent by name still needs a release (Figure 2). And the rules catch the failures the team thought to write down. A person still owns the ones nobody anticipated, which is why the failed attempts are kept where a person can read them. ### What to do first, before you buy anything **1. Find every place your applications call a model.** For each one, write down the goal, the expected shape of the answer and the rules an answer must meet. If you cannot write the rules, you have found a call that is not being checked at all. **2. Count your retry loops.** Note how many attempts each allows, what it sends back to the model on a retry, and whether it keeps the failed attempts. Differences between them are differences in behaviour your users already see. Figure 3 is the inventory you are taking: everything on its left side is code your team wrote and now maintains. Figure 3. The same model call, before and after. The model call does not change; what changes is who writes and maintains the machinery around it, and where the rules live. (Figure, described: Left, before: around one model call, code written by hand at each call site: prompt text as string constants, parsing the reply, validating each field, a retry loop that resends the same prompt, business rules as if statements, and logging that keeps only the final answer so failed attempts are lost. Right, after: the team's .NET type and the code that states the intent; an intent file holding the wording, examples, rules and version; the library supplying the call, parsing, the check against type and rules, retry with the findings, fallback to the next provider, every attempt kept and the limits enforced; the code receives a typed value.) **3. Trace the rule that changes most often.** Pick it and follow what it takes to change it today: who edits it, how long until it reaches production, and how you would prove later which version was in force. That trace is the case for moving it into a versioned file, and it tells you how much a release-free change is worth to your team. These steps cost nothing but time. They show whether your model calls are checked or merely hoped for, and they give you a concrete starting point whatever you decide next. ### How C2Consultants does this IntentSharp is our .NET library for exactly this, and the program scale of Cognitive Infrastructure, our method. Developers express application behaviour as intent, apply it to ordinary .NET values and methods (text, records, lists, a DataTable or JSON, or an `[AIIntent]` method that replaces one interpretation step inside a method you already have), and move the changeable wording and rules into JSON or YAML intent files. It checks each answer against your .NET type and your rules, retries with the findings within the limits you set, keeps every attempt, and keeps the last good version when a saved edit is bad. It runs on .NET 8, 9 and 10 with OpenAI, Anthropic or any `IChatClient`, including a local model on Ollama; data goes only to the model providers you configure, and the licence key is checked offline. Our estimate for a typical business application is 20 to 40% less C# code; that is an estimate, not a measurement. One honest limit: when the running application proposes an edit to a definition, the library applies it by default and ships no review layer, so a team that wants changes reviewed before they run wraps the writer and holds the edits it flags as widening. C2Empowered, our operations platform, is built on IntentSharp and applies the same separation at the scale of an organization. IntentSharp 1.0 is [on NuGet](https://www.nuget.org/packages/IntentSharp) for .NET 8, 9 and 10, with [documentation at intentsharp.com](https://intentsharp.com/docs/). It is commercial software, not open source, licensed from $349 per developer per year with unlimited deployments, and you can evaluate it free for 30 days on development and test systems at https://intentsharp.com/pricing. *Next chapter: A Tuesday, before and after. What changes for the people who do the work when the routine part of it runs through a governed platform.* ## A Tuesday, before and after Source: https://www.c2consultants.net/writing/a-tuesday-before-and-after/ Subtitle: Chapter 6 of Managing AI that does the work For: Operations leaders Published: 2026-11-02 ### Where this chapter sits The earlier chapters made the argument from the top: why a written policy does not govern anything, why authority has to stay with named people, what AI should cost, and where the time in a process actually goes. This chapter makes the same argument from the floor. It follows one recurring task through one ordinary day, twice, and asks the question an operations leader asks first: what changes for the people who do the work? ### The problem, as you would put it It is Tuesday. A request arrives by email. Someone on your team opens it and checks six fields against a spreadsheet. They sign in to a government portal, type the six fields in, save, confirm, and file the confirmation where the next person can find it. About fifteen minutes, if nothing is wrong. Then the next email. It comes about a hundred times a week. Nobody would call this hard work. It is careful work, and that is the trouble. The person doing it is skilled enough to notice when a field looks wrong, and spends most of the day typing fields that are not wrong. When that person is out, the backlog waits, because nobody else remembers which spreadsheet column matters. When the portal changes a field, nobody notices until the first rejection comes back. Figure 1. The filing clerk's day, before and after. The same filings arrive. Before, typing them is the day; after, the person's day is the approvals and the one run that stopped. (Figure, described: Two horizontal timelines of the same working day. Before: the person's lane is filled with filings back to back, each about fifteen minutes by hand. After: the workflow's lane carries many short runs, each 112 seconds, measured as the median of the last 18 runs, and the person's lane holds only approvals and one exception where a run stopped. The layout is illustrative and not to scale.) None of this shows up as a crisis. It shows up as a backlog after a holiday, a rejection nobody can explain, and a team that cannot take on anything new because the old work fills every hour. ### Why the usual fixes do not close the gap The first fix is another person, or cross-training the ones you have. That covers absences. It does not change the work: two people now type the same fields, and the portal change still surfaces as a rejection. The second fix is a script or a recorder that types the fields for you. It is faster on a good day. On a bad day it types confidently into the wrong field, because nothing tells it to stop, nobody approved what it saved, and nothing records what it saw. When the portal moves a field, it fails silently or noisily, and either way somebody has to work out after the fact what it did. The third fix is to wait for a better system. The portal belongs to someone else, the spreadsheet is how the team has always worked, and the old Windows application has no API. Nothing is going to be replaced on your timetable. The fourth fix is to hand people an AI chat tool. They can paste the email in and get the six fields back. They still sign in, still type, still save, and the only record is a chat window nobody else can read. Each of these treats the problem as typing speed. The problem is that the work has no shared place to live. It exists in one person's head and one person's inbox, and it is visible to everyone else only when it goes wrong. ### The idea: the platform follows the work The thesis describes the change as giving people a common place to direct work across the systems they already use. The point is not a faster way to type. It is that the work becomes a thing with a state that others can see: a request that arrived, a filing that is waiting for a decision, a run that stopped and the reason it stopped. As the thesis puts it: "People can see what is underway and what needs their attention without carrying every field manually between systems." (C2Consultants, *Intelligent Software and Autonomous Organizations*.) That sentence describes three different jobs, and they belong to three different people. The person who did the typing now makes the decisions that need a person: is this right, approve it; is this odd, look at it. The supervisor who owned the backlog now owns a queue. The auditor who used to ask around now reads a record. Figure 2. The supervisor's queue. The three questions a supervisor asks every morning, answered in one place: what needs me, what happened, and what stopped and why. (Figure, described: A single panel with three columns. Waiting for approval: filings that are about to be saved, each showing what it will do and the data it saw, with Approve and Reject buttons. Ran: filings that were approved and whose confirmation was filed, each with its version and trace. Stopped, and why: one run that stopped before saving because a portal field it expected was not there, and one exception sent back to the person because a required field was missing from the email.) The thesis names what makes this different from a faster script: "The larger change is continuity: an outcome remains visible as it moves through several systems, waits for a decision, encounters an exception, or resumes after an interruption." (C2Consultants, *Intelligent Software and Autonomous Organizations*.) A filing that stopped is not a failure somebody discovers next week. It is an item in a queue with its reason attached. ### The same Tuesday, after The request arrives by email, as before. The workflow reads it, checks the six fields against the spreadsheet, signs in to the portal and fills in the fields. Before it saves, it stops. One card appears in the supervisor's queue: what it is about to do, with the data it saw. A person approves or rejects. On approval it saves, confirms, and files the confirmation. The record shows who approved it, when, which version of the workflow ran, and what it saw. The machine's part of that filing takes 112 s, Measured (the median of the last 18 runs), against 10–20 minutes by hand, which is the customer's own estimate. The person's part is the approval and the exceptions. Then the portal changes a field. Before, that was a rejection nobody could explain. Now the run stops before saving and reports what it found, and the item sits in the stopped column with the reason. The workflow is adjusted once. The AI is used again only when a source changes shape, not every time the data does, which is the cost argument of chapter 3 seen from the floor. And when the person who knows the filing is out, the backlog no longer waits for them. Which spreadsheet column matters, which six fields are checked and where the confirmation goes are written into the workflow, not kept in one person's memory, so whoever covers the queue that day is approving the same steps, checked the same way. A request that does not fit, a missing field or an odd value, does not get typed in anyway; it comes to a person with the reason attached, and the decision they make is recorded against the run. Figure 3. Three people, three different mornings. The work did not move to a new system; the view of it did. (Figure, described: Three columns: the person doing the work, the supervisor and the auditor, each with what they see before and after. The person goes from re-keying every request to reviewing and approving, with exceptions arriving with their reason. The supervisor goes from finding a portal change at the first rejection to one queue of what waits, what ran and what stopped. The auditor goes from a name recalled from memory to a named approver, a time, the version that ran and the data it saw.) It is worth being precise about what did not change. Your systems of record stay: nothing is replaced, and the workflow uses the applications and portals you already have, including the ones with no API. Someone still owns the outcome and answers for it; that person now supervises ten runs instead of typing one. Nothing sends, saves or acts in an application without an approval, unless an administrator deliberately grants a standing approval for a routine step. And it runs on your own server, with a local AI model by default. ### What to do first, before you buy anything **1. Time one recurring task honestly.** Pick the task your team does most often by moving information between email, portals, spreadsheets and an old Windows application. Time it over a normal week, including the rework. That number is your baseline, and it is the only one that will matter later. **2. Write down where it must stop for a person.** Walk the task step by step and mark every point where something is saved, sent or submitted. Those are your approval points. Name who approves at each one. If nobody can be named, you have found the first thing to fix. **3. List what goes wrong and how you find out.** Missing fields, a portal that changed, a request that does not fit. For each, write how you learn about it today. If the answer is a rejection or a complaint, that is the visibility the queue in Figure 2 would give you. These steps cost an afternoon. They give you the baseline, the approval points and the exception list that any serious attempt to change the work will need. ### How C2Consultants does this C2Empowered is our operations platform, and this chapter's Tuesday is the work it was built for. A workflow reads the request, checks it, and acts in the portal through a browser session or in a Windows application through a Fleet Agent on a signed-in desktop; the steps that save, send or act stop at approval gates set by risk level for a named approver; every run keeps a step-by-step trace tied to the version that ran; and the supervisor sees one queue of what waits, what ran and what stopped and why. Two honest limits: it drives Windows applications and browsers, not mainframe screens or Citrix sessions, and it runs one workflow at a time per Fleet Agent today. The way to start is a pilot on one process, measured before and after: discovery ($2,000), installation on your server ($1,750), and building and testing the workflow ($175 per hour), run side by side with how your team works today. *Next chapter: Websites other software can use. Where this leads between organizations.* ## Websites other software can use Source: https://www.c2consultants.net/writing/websites-other-software-can-use/ Subtitle: Chapter 7 of Managing AI that does the work For: Founders and product leaders Published: 2026-11-02 ### Where this chapter sits The earlier chapters stayed inside one organization: who may act, what it costs, where the time goes, how a developer puts a model into an application, and what changes for the people doing the work. This chapter crosses the boundary between organizations. It asks where the same ideas lead when one company's software needs to do business with another's. Say it plainly before anything else: this chapter describes a direction, not a product C2Consultants sells today. Nobody can buy a finished version of what follows, from us or from anyone. What any company can do now is the first step, and the chapter ends with it. ### The problem, as you would put it Your website was written for people. It has a home page, product pages, a pricing page and a contact form. It was designed to be read, compared and acted on by someone sitting at a screen. A growing share of the visitors are not people. They are software acting for a person: an assistant asked to find three suppliers and compare their terms, a purchasing system checking availability, a research tool building a shortlist. That software reads pages that were never meant for it. It guesses which number is the price, whether the item is in stock and what the delivery terms are. When it guesses wrong, the person it works for sees a confident answer that your company never gave. The requests that do reach you arrive the old way. Someone reads an email or a form, works out what the sender meant, and types it into your own systems. Chapter 4 called this repeated translation. At the edge of the company it is still there, it is still done by hand, and it still loses meaning on the way. So a founder ends up with two problems. Software is already describing your business to other people, from pages it cannot reliably read. And every request that comes in still has to be translated by a person before any work can start. ### Why the usual fixes do not close the gap The first fix is a chat assistant on the website. It answers questions fluently, and that is the trouble. A fluent answer is not a commitment. Unless the assistant reads your actual stock, prices and terms, and unless your rules decide what it may promise, it can say things your company cannot honour. The second fix is a public API. That is closer, because software can call it. But an API usually exposes operations, not meaning. It says which fields to send. It rarely says what outcome the call produces, which limits apply, or who is allowed to commit the company. Each customer's developers still have to learn those things from a person and build them in by hand, one integration at a time. The third fix is to write pages that read well to search engines and AI summaries. That helps software describe you more accurately. It does not let anyone request work, and it says nothing about who may act. The fourth fix is to wait for a standard. Standards will come, and they will help. But a standard for the format does not decide your outcomes, your constraints or your authority for you. Those are business decisions, and they can be written down now. Each fix handles one part. None of them publishes, in one place software can read, what the company offers, what a request needs, what limits apply and who may authorize it. ### The idea: one set of capabilities, two faces Our thesis describes the website we expect: pages for people and a governed service interface for software, both expressing the same business capabilities. People browse, compare and ask. Authorized software performs the same discovery, clarification and request through explicit contracts. Figure 1. A website with two faces. The person and the software reach the same capabilities, grounded in the same records. The red line is the one a chat assistant on its own cannot provide. (Figure, described: Three columns. Left: pages for people, where a person browses, reads terms, asks a question and fills in a form. Centre: one set of business capabilities, such as quoting a stocked item, checking availability, proposing delivery dates and accepting an order. Right: a governed service interface for software, which discovers what is offered, reads inputs and constraints, asks for missing details and requests work with authorization. Both faces read from the same records and rules underneath.) Two properties make the software face different from a chat assistant or a bare API. The first is grounding. The thesis is blunt about it: "A model's fluent answer cannot establish stock, price or a contractual commitment by itself." (C2Consultants, *Intelligent Software and Autonomous Organizations*.) A model can help the interface understand an unusual request or clarify a vague specification. The offer itself must come from the company's records and the company's rules for accepting an action. The second is a published description. Before software can use a service sensibly, it needs to know four things, and a person needs to know the same four. What outcomes does the service produce? What must a request contain? What limits apply before anything is promised? And who may ask, and who may commit? Figure 2. What a service description must publish. The same four questions this series has asked of a program and of an organization, asked now of a company's public face. (Figure, described: A table of four rows. Outcomes: what the service can accomplish, for example a firm quote for a stocked item with a delivery date. Accepted inputs: what a request must contain and in what shape, for example the part or specification, quantity, site and needed-by date. Constraints: the limits that apply before anything is promised, for example the regions served, any minimum order and how long a quote holds. Authorization: who may request and who may commit, for example anyone may ask for a quote while an order needs an account and a mandate.) Those four are the same questions the series has asked all along: what it means, what it requires, who may use it and what happened when it ran. Inside a program they become types and rules. Inside an organization they become a workflow with an approver. At the edge of the company they become a public description that people and software can both read. ### What it looks like across two companies The thesis uses one example to show the whole architecture, and it is worth following. A project manager asks for an approved replacement for 500 metres of cable, delivered to Site 12 by Friday, with the offers compared and the best one recommended. The example is illustrative; no company runs it end to end today. Figure 3. A purchasing request across two companies. Each side keeps its own records and its own authority; what crosses the boundary is a request, an offer and an acknowledgment. (Figure, described: Left, the buyer's company: a project manager's request enters the operations platform, which holds the specification, inventory, approved suppliers and purchasing policy, records the task and evidence, and compares offers. The platform exchanges requests and clarifications with two suppliers' governed interfaces on the right, each grounded in its catalog, stock and delivery terms. Purchasing passes through a separate gate that needs its own mandate; without one, a person decides. An accepted order produces a durable acknowledgment that both sides reconcile against.) Inside the buyer's company, the operations platform gathers the project specification, the stock already on hand, the approved suppliers and the purchasing policy. It routes any interpretation to a model under the company's own rules for what that model may see, and it keeps a record of the task and the evidence behind each option. The request then goes to the suppliers' governed interfaces. Each one asks for whatever is missing and returns an offer based on its actual catalog, stock and delivery terms. Each supplier stays responsible for what it offers and for the conditions under which an acceptance becomes an order. The buyer's platform compares the offers and explains its recommendation. Here the example draws the line chapter 2 drew inside one company. The instruction to research suppliers authorizes research, nothing more. Buying needs a separate mandate. If none applies, the decision goes to a person. If a bounded mandate does apply, the platform can accept within its limits and must obtain a durable acknowledgment of the order. That acknowledgment matters most when something goes wrong. If the connection drops halfway through, neither side should guess. Both look at the task and transaction records to establish whether an order was accepted before anyone tries again. The result is a purchase whose meaning, authority and outcome can be inspected on both sides of the boundary. Notice what made it possible. Not a smarter model, but four things each supplier had published and stood behind: what it offers, what it needs, what limits it keeps, and who may commit it. ### What to do first, before you build anything **1. List what you offer as outcomes, not pages.** Write down the things a customer actually comes to you for: a quote, a booking, an assessment, a delivery. Your site map describes pages. This list describes capabilities, and it is usually shorter and clearer than the site. **2. For each outcome, write down the other three answers.** What must a request contain before you can act on it? What limits apply: regions, minimums, lead times, eligibility? Who may ask, and who in your company may commit to it? If you cannot answer the last question, you have found a gap that matters long before any software arrives. **3. Publish a machine-readable description of what you offer and how a request is made.** This is the first step any company can take, and it needs no new platform. A plain, structured file on your own site, stating your offerings, their inputs, their constraints and how a request reaches a person, already lets software describe you from your words rather than its guesses. Say honestly who answers and how. None of this commits you to automating anything. It makes you legible, to people and to software, on your own terms. ### How C2Consultants does this We have taken the first step on our own site, and only the first step. The site publishes a sitemap; an llms.txt file that tells software what the site is and where things are; an llms-full.txt file with the plain text of our writing and pages; and a manifest at /.well-known/c2consultants.json that describes each of our offerings, what it needs to start, the constraints that apply and how a request is made. Since November 2026 the site also answers programs through a small API: a catalog to read, requests and order requests to send, each acknowledged by email with an id, each confirmed by a person before anything is charged or started. A page for software, For agents and other programs, lists those files in one place. The honest limit is the one this chapter turns on: there is no governed interface behind them that performs work. A request sent through the site is read and answered by a person, and there is no automated ordering. The service web this chapter describes is the direction we are working towards, not something we sell. What we sell today sits one scale down: C2Empowered, the operations platform, does inside one organization what the buyer's side of the example does, holding a task, its evidence and its approvals in one governed place, and the way to start is a pilot. *This chapter closes the series Managing AI that does the work: moving people from doing the work to governing it.* # Pages - Home: https://www.c2consultants.net/ — the company, its products and how to start. - Products: https://www.c2consultants.net/products/ — one method, three products. - C2Empowered: https://www.c2consultants.net/products/c2empowered/ — the operations platform, proof, savings calculator and pilot pricing. - IntentSharp: https://www.c2consultants.net/products/intentsharp/ — typed, checked AI calls for .NET. - Binary Intelligence: https://www.c2consultants.net/products/binary-intelligence/ — self-healing Windows fleets. - Our approach: https://www.c2consultants.net/approach/ — Cognitive Infrastructure, our method, the thesis behind it, and what it means for your business. - Writing: https://www.c2consultants.net/writing/ — "Managing AI that does the work", a series on moving people from doing the work to governing it. - Services: https://www.c2consultants.net/services/ — C2Empowered pilots and implementation, the IT practice, and partners. - Co-Managed IT: https://www.c2consultants.net/services/co-managed-it/ — director-level IT above an internal T1. - T3/T4 Architecture & IT: https://www.c2consultants.net/services/t3-t4-architecture/ — the team other MSPs escalate to. - IT Projects & Migrations: https://www.c2consultants.net/services/projects-migrations/ — migrations and projects with a real rollback path. - For operations leaders: https://www.c2consultants.net/operations-leaders/ — what changes for the people who do the work, the supervisor and the auditor. - Partners: https://www.c2consultants.net/partners/ — how MSPs, consultancies and integrators deliver C2Empowered for their own clients. - About: https://www.c2consultants.net/about/ — the company, leadership and credentials. - Talk to us: https://www.c2consultants.net/contact/ — contact form and direct contact details. - For agents and other programs: https://www.c2consultants.net/for-agents/ — the machine-readable files this site publishes, and their limit. Also: https://www.c2consultants.net/llms.txt (the short version of this file), https://www.c2consultants.net/sitemap-index.xml.