Dramatic music. A single spreadsheet tab, still open, glowing in an otherwise dark office.
Narrator: “Last season, the Alliance of the Spreadsheet People formed to resist the new system. The consultants recruited them instead of fighting them. Requirements gathering is done. Now the tribes face the challenge that ends more Enterprise Resource Planning (ERP) projects than any go-live disaster: designing the chart of accounts (COA), the numbered list of every account the general ledger (GL) will ever use.”
If you are the controller who has to sign off on that list, this is the episode for you. The lessons are in the commercial breaks, same as always.
A chart of accounts looks like plumbing — dull, structural, easy to defer. It is actually the single decision that determines whether your month-end close is fast or painful for the next decade. A bloated COA, with a separate account for every project, customer, or department, turns every financial report into a scavenger hunt and every new hire into a six-month COA archaeologist. A COA that is too thin loses the detail management actually needs.
For a Denver light-manufacturing or distribution shop, this shows up as a very specific pain: finance wants to slice profit by project, operations wants to slice it by product line, and everyone’s instinct is “add more accounts.” Do that enough times and a chart designed for 200 accounts balloons to 2,000, nobody remembers what half of them are for, and closing the books means reconciling accounts nobody has posted to in three years.
Host: “Today’s challenge: each tribe proposes a chart of accounts structure. The tribe whose structure survives contact with an actual audit wins immunity.”
Linda: “We need one account per project. We track 47 active projects. That’s 47 new accounts, times however many expense categories, times two for this year and next.”
Sarah (already building the account-numbering spreadsheet): “So somewhere around six hundred new posting accounts, conservatively.”
Dave: “And we keep the old chart too. Just in case.”
Commercial break — the lesson: This is the classic mistake, and it comes from a real need: Linda’s team needs to report profit by project. The wrong fix is a GL account per project. The right fix is a dimension — a tag you attach to a transaction (project, department, location) that lets you slice reports without multiplying the chart itself. Microsoft’s own guidance on designing a chart of accounts for Dynamics 365 Business Central puts it plainly: “start simple with fewer G/L accounts” and “use dimensions to simplify your chart of accounts — don’t have specific G/L accounts for each product or department.” One clean expense account with a project dimension answers Linda’s question and every other cut she will ever ask for, including the ones she has not thought of yet.
Bob: “We don’t need 47 project accounts. We need our own inventory adjustment account, our own scrap account, and a way to fix mistakes without waiting for anyone’s approval.”
Carol: “What do you mean, ‘waiting for approval’? Bob just posts the correction himself. He’s been doing it since the Reagan administration.”
Mike: “It’s called the emergency override procedure. Bob has the login. Bob makes the fix. Bob moves on.”
Bob (proudly): “Twenty minutes, start to finish. No meetings.”
Commercial break — the lesson: Bob’s “emergency override” is a segregation-of-duties gap, not a shortcut — the same person who identifies an error, approves the correction, and posts it, with nobody else reviewing it. It survives in a legacy system because nobody’s looked in years. It will not survive a lender’s or insurer’s first real audit, and it is exactly the kind of finding that turns a clean review into a management-letter comment. The fix is not to accuse Bob of anything; his corrections are probably right. The fix is a second set of eyes: a same-day review queue, or a threshold above which someone else approves before the entry posts. That takes Bob from twenty minutes to maybe forty-five, and it takes segregation of duties from “trust Bob” to “provable.”
Jennifer: “What if we just gave both tribes everything they asked for? More accounts, more overrides, more flexibility.”
Tom (flipping through his binder): “The methodology recommends a standard chart of accounts with minimal customization, but it also has a whole appendix on flexibility, so—”
Alex: “I could build a report that hides the accounts nobody uses. Problem solved.”
Commercial break — the lesson: “Give everyone what they asked for” is not a design decision, it is the absence of one, and it is how a 200-account chart becomes a 2,000-account chart within eighteen months. Someone has to own the chart of accounts as a single artifact — usually the controller, with the implementation partner as a sounding board — and say no to additions that a dimension, a report filter, or a saved view can handle instead.
Guest Judge: “Every account request goes on one of two lists today. List one: things that change the actual financial structure of the business — a new legal entity, a new revenue stream, a new tax jurisdiction. Those get new accounts. List two: things you want to slice, filter, or report on — a project, a customer, a sales rep, a department. Those get dimensions.”
Linda (reading the lists): “…my 47 projects are all on list two.”
Guest Judge: “Every one. You’ll get project-level profitability without a single new account.”
Bob (quieter now): “And the override procedure?”
Guest Judge: “Stays, with one change: a second approver on anything over a threshold you set. You keep the speed. The business gets the proof.”
Commercial break — the lesson: Most chart-of-accounts fights are really reporting fights wearing a structural costume. Separating “this changes what the business is” from “this changes how I want to view what the business already does” resolves the majority of them before a single account number gets assigned.
Redesigning your chart of accounts as part of a bigger system change? See our [[ERP consulting]], including the financial and control design work that keeps Linda’s reporting and Bob’s speed both intact.
Based on patterns observed across dozens of ERP implementations. The characters are fictional. The chart of accounts disputes are not. No project codes were harmed in the making of this episode — 46 of them were, mercifully, retired in favor of a dimension.
Next episode: “User acceptance testing tribal council,” where Mike discovers what thirty years of undocumented data actually converts into, and the alliance faces its first vote.
]]>Twenty-four centuries ago, in the opening pages of Plato’s Republic, a rhetorician named Thrasymachus lost patience with a polite conversation and threw a grenade into it: justice, he said, is nothing else than the interest of the stronger. Whoever holds power writes the rules, writes them for their own benefit, and then teaches everyone else that obeying them is virtue. The shepherd fattens the sheep, he added — but not for the sheep.
Socrates out-argued him, Plato wrote the minutes, and philosophy has spent two thousand years treating the line as the villain’s opening bid. But run it through one substitution and it describes the technology market a small business buys from with uncomfortable accuracy. Nobody in software procurement says “justice.” We say “best practice.”
Think about where the rules of a technology decision actually come from.
The reference architecture that shows “how it’s done” was published by a vendor, and the way it’s done runs, by a striking coincidence, straight through that vendor’s product line. The analyst reports that grade the market are produced by research firms whose paying relationships — briefings, subscriptions, reprint licenses — flow in significant part from the companies being graded. The conference talk on the modern data stack was sponsored. The certification that makes your new hire “qualified” was designed by the platform it certifies people on, which means your training budget is also their retention program.
None of this requires anyone to lie. It only requires everyone to publish their own perspective and call it the industry’s. Each rule is genuinely a rule; the question Thrasymachus taught us to ask is merely whose interest it was written in. Per-seat pricing is “standard.” Auto-renewal is “standard.” Charging you to take your own data out the door is “standard.” Standard, in each case, for whom?
There’s a second-order version of the problem that hits a small and medium business (SMB) hardest: most “best practice” is written for enterprises, because enterprises are who the authors sell to. A control framework designed for a 5,000-seat company arrives at a 20-seat machine shop on the Front Range as received doctrine, unexamined — three layers of tooling to solve problems the shop will never have, priced in a currency the shop doesn’t print. The rules were not written against the small firm. They simply weren’t written for it, and following someone else’s rules by default is how you end up funding someone else’s roadmap.
Here is the part of the old argument that procurement teams rediscover the hard way: the evidence you research from is not a neutral archive.
A case study is a story about a project that survived, written by the party that got paid, approved by a marketing department, and published because it sells. The Enterprise Resource Planning (ERP) implementation that cratered — blew the budget, burned the controller out, got quietly rolled back to QuickBooks — publishes nothing. It signed a mutual non-disparagement clause on the way out. The result is a public record with the failures surgically removed, which is to say: a record of the stronger party’s wins, presented as the odds.
The old proverb “nobody ever got fired for buying IBM” is the same mechanism wearing a safety vest. It sounds like risk management. Read it again and it’s an incumbent’s market position, restated as your career advice. The safe choice is safe for the person choosing, precisely because the record — who gets blamed, who gets believed — was arranged by the strong before you walked in.
And the newest research shortcut inherits all of it. Ask an artificial intelligence (AI) chatbot for the best platform in any category and you get a fluent summary of the published record — the vendor content, the sponsored comparisons, the survivor case studies. The model doesn’t launder the bias out; it compresses it and returns it with confidence. Training data is the record of whoever published most, and we’ve just established who that is. An AI answer about the market carries the politics of its corpus, delivered in a tone that suggests it carries none.
Plato’s rebuttal to Thrasymachus is the most useful sentence in the whole exchange for anyone who buys — or sells — expertise. No craft, Socrates argues, serves the practitioner insofar as it is a craft. Medicine, as medicine, seeks the patient’s health, not the doctor’s income. A pilot, as a pilot, gets the sailors home. The moment the practice starts optimizing for the practitioner, it has stopped being the craft and become something else wearing its badge.
That is the cleanest test of advice ever written, and it converts directly into a procurement standard: never ask whether an adviser is smart; ask whom the advice structurally serves. Not their intentions — their incentives. A consultant paid a reseller margin on the software they recommend is not lying to you, but their craft has a second client. A proposal whose every option lands inside one vendor’s ecosystem was not written by your side of the table, whatever the letterhead says.
You cannot fix this with trust. You fix it with arrangements — advice whose interests are inspectable. Recommendations in writing, with reasoning, so they can be argued with. Disclosure of what the adviser earns from each path. Deliverables you own outright: documentation, credentials, the data model, the export scripts. It’s the reason our own doctrine is vendor-neutral [[IT strategy]] and systems a client can own and leave with — including leaving us. An exit that stays cheap is the only guarantee that keeps everyone’s craft honest, ours included.
Thrasymachus can’t be refuted from a position of weakness — but he can be managed. The weaker party’s move is not to overpower the strong; it’s to stop mistaking their interests for laws of nature. Five questions do most of the work:
None of this is cynicism. It’s the opposite: it takes the market seriously enough to read it accurately. Vendors are not villains, analysts are not liars, and the proverb about IBM contains real wisdom about integration risk. The point is smaller and sharper — every rule in your inbox was written by someone, in some interest, and a business that asks whose buys better than a business that doesn’t.
The Republic runs nine more books because the question deserved more than a heckle. Your next software decision deserves more than a case study written by the seller. If there’s a proposal, a renewal, or a “standard architecture” on your desk and you’d like a second reader whose only interest in it is yours — tell us what you’re weighing, and we’ll go through it question by question.
]]>Sheet1 (final)(v3)(USE THIS ONE), and a formula in cell M14 that the entire month-end close depends on. The person who maintains it does not call themselves a programmer. They call themselves someone who is good at Excel.
They are wrong about the first part. Advanced spreadsheet work is programming with the syntax filed off — not “like” programming, not “a stepping stone toward” programming, but the thing itself, done in a cell instead of a code file. And once you accept that, two conclusions follow that most small and medium businesses (SMBs) haven’t acted on: you employ a programmer you aren’t using as one, and you run production software you aren’t managing as software.
Open a formula written by someone who actually lives in Excel — not the =A1+A2 crowd, but the person who builds the pricing model or the commission calc. You’ll find something like this:
=IFERROR(INDEX(Rates,MATCH(1,(Region=$B5)*(Tier=$C5),0)),"check inputs")
Ignore the spreadsheet costume and read what’s happening. There’s a lookup against a named range. There’s a compound condition — region and tier both have to match — built by multiplying two arrays of true/false values, because the author worked out that TRUE * TRUE = 1 and constructed an AND out of arithmetic. And there’s error handling: when the lookup fails, it doesn’t spit out a cryptic #N/A, it returns a message a human can act on.
Written in Structured Query Language (SQL), the language your accounting system’s database already speaks, the same logic is a two-condition WHERE clause. Written in Python, it’s a five-line function. The logic, the data structures, and the defensive habits are identical — only the vocabulary and the job title change.
Strip the branding off the things your best Excel person does every day and the list reads like a junior developer’s job description:
IF, INDEX/MATCH, SUMPRODUCT — conditional logic and lookups. Control flow and data structures, expressed in a grid.GROUP BY, JOIN, and WHERE wearing a drag-and-drop interface. Someone who builds a pivot off three source tables already understands relational data; they’re missing the word “SQL,” not the concept.These aren’t skills adjacent to programming. They’re the same skills, learned in the one environment that ships on every corporate laptop and never asks anyone to install anything.
Here’s where this stops being a compliment and becomes a line item on your risk register.
If the argument above is right, then the model your quarter runs on is production software — and you are maintaining it with no version history, no testing, no review, and exactly one person who understands it. A formula buried in M14 can’t be code-reviewed. It silently changes meaning the day someone inserts a column. There is no audit trail for a workbook on a shared drive; there is only “who touched the model,” asked in an accusatory tone during close week.
Calling it “just a spreadsheet” doesn’t make the risk smaller. It only makes the risk invisible. The exposure comes in three familiar flavors: key-person risk (the author resigns and takes the only working mental map with them), silent-error risk (a broken formula that still produces a number), and audit risk (a material figure whose lineage nobody can reconstruct). None of these shows up on a budget until the week it costs you the close.
The honest version of this argument also names the walls, because Excel’s limits are published, not mysterious. A worksheet tops out at 1,048,576 rows — Microsoft’s own specifications page lists the ceilings — and a model gets miserable long before that, when every recalculation takes a coffee break. Repeatability fails next: a workbook can’t be meaningfully tested or diffed. Integration fails last: Excel can be bullied into calling an application programming interface (API) or scheduling a nightly job, but at that point someone is writing a program inside a spreadsheet to avoid admitting they should write a program.
None of those walls proves your Excel person isn’t a programmer. The opposite: the person who looks at a wheezing 400,000-row workbook and says “this wants to be a database” has just made a senior engineering judgment. They only need someone to confirm they were right and hand them the tools — usually a small reporting database and a business intelligence (BI) layer like Power BI, which is exactly the shape of work our data and BI practice does for Denver SMBs that have outgrown the grid.
Three moves, in order of urgency:
(final)(v3). A one-page note on what the model assumes. This costs days, not months, and removes the scariest single point of failure in your reporting.The most fluent programmer in your office may be the one who never opened a terminal. Check the formula bar before you decide who’s technical — and if you’d like a second set of eyes on your shadow software portfolio, tell us what’s in cell M14.
]]>Whether to move off QuickBooks is not a technology question. It is a spend decision with a return you can calculate, and the person who signs the close is the one who should own it. The trap is treating it as a preference — a nicer interface, a newer vendor — when it is really a threshold problem. Below the threshold, QuickBooks plus discipline is the right, cheap answer. Above it, staying costs more every month than moving would, and the cost hides in labor and risk instead of on an invoice.
So the useful question isn’t “is QuickBooks good enough?” It’s “what is the status quo actually costing us, and has that number crossed the line yet?” Everything below is about finding that line.
These are the patterns that separate a real ceiling from a setup you configured badly. One of them alone rarely justifies a migration. Two or three together usually do.
Here is the framing that turns this from opinion into arithmetic. The cost of staying is real; it’s just unbilled. Put a dollar figure on three lines and the decision usually makes itself.
Add those up as an annual number. That’s your cost of inaction. It is the honest thing to weigh a migration against — not the QuickBooks subscription, which was never the expensive part.
A migration is a real project with a real budget, and anyone who quotes you a fixed price before seeing your data is guessing. Think in ranges across three buckets:
The timeline that governs the budget: a mid-market Enterprise Resource Planning (ERP) implementation typically runs about five to seven months from decision to go-live, and that assumes someone internal can own it without dropping their day job. The largest hidden cost of the whole project is that person’s time — the months your best operator spends on migration instead of running the business. It sinks more projects than the sticker price does. We work these numbers as scoped ranges, never a fixed quote, and you should be suspicious of anyone who does otherwise.
Before you evaluate a single platform, document your own numbers. This is the deterministic part of the decision, and it comes first — you cannot compare systems against requirements you haven’t written down. Write down, on one page — the same inventory the [[Outgrowing QuickBooks: is it time for ERP?]] guide walks through step by step:
That page is worth more than any vendor demo. It’s the artifact that lets you compare platforms against your reality instead of against a sales narrative, and it’s the difference between choosing a system and being sold one.
There is no single right answer, and any advisor who leads with one before seeing your inventory is selling, not advising. Oracle NetSuite, Microsoft Dynamics 365 Business Central, and — for more companies than vendors like to admit — a well-configured QuickBooks with the spreadsheets retired are all legitimate destinations depending on entity count, inventory complexity, transaction volume, and how much internal capacity you have. The right target is whichever one your one-page inventory points to. We stay neutral on purpose and build systems you own and could leave with, because the point is a platform that fits your numbers, not a vendor you’re locked into.
If two or three of those signals are true and your cost-of-inaction number has crossed your migration number, the move is worth doing once and doing well. A scoped assessment — your one-page inventory, what you actually need, and whether to fix the model or replace it — is the cheapest way to avoid a six-figure mistake. See [[ERP consulting]] to start there.
]]>When we inventory software at small and medium businesses (SMBs), we typically find somewhere between a handful and a dozen AI tools in active use that nobody approved — free chatbot accounts, browser extensions, note-takers quietly sitting in on client calls. Each one is a place where company or client information now lives outside your control.
That exposure lands differently by industry. For a Denver law or accounting firm, a paralegal pasting a client matter into a personal chatbot account may have just stretched a confidentiality duty past its limit. For a dental clinic, patient details in a consumer AI tool are a Health Insurance Portability and Accountability Act (HIPAA) problem whether or not anything bad happens next. And on many free consumer tiers, the vendor’s terms allow your inputs to be used for model training — which means “just delete it” may not be an option later.
The instinct is to ban everything. That fails within a month: the staff who found these tools useful keep using them on personal devices, and now you carry the same exposure with zero visibility. The policy that works gives people a sanctioned way to do what they were already doing.
A workable SMB policy fits on one page and answers three questions.
What’s allowed without asking. Drafting and editing internal documents and emails. Summarizing meeting notes and public information. Writing or reviewing code in company repositories. Brainstorming and research starting points. All of it on approved tools under company business accounts — business tiers generally offer admin controls and contract terms that exclude your data from training, which free tiers may not.
What’s banned without written approval. Client-identifying or client-confidential information. Employee, payroll, or health records. Passwords, keys, and security configurations. Personal AI accounts for any company work. And the big one: sending AI output to a client, court, or regulator without a named human reviewing it first.
What gets logged. Which tools are approved and who holds the accounts. Who reviewed AI-assisted work before it left the building. And for material decisions — pricing, hiring, anything that touches the books — the tool, the prompt, the output, and the reviewer.
If you want a framework behind those choices, the National Institute of Standards and Technology’s (NIST) AI Risk Management Framework is the reference we use. In plain terms it asks for four things: govern (someone owns the policy), map (know where AI is actually used), measure (check the outputs), and manage (fix what the checks find). A one-page policy, a tool inventory, and a quarterly review cover all four at SMB scale.
Adapt the brackets, delete what doesn’t apply, and resist the urge to add legal boilerplate. A policy nobody reads is a policy nobody follows.
AI acceptable-use policy — [Company name]
Effective [date] | Owner: [name, role] | Reviewed: quarterly
1. Approved tools
- [Tool A] under the company business account only
- [Tool B] under the company business account only
- Anything else requires written approval from [owner/role]
2. Allowed without asking
- Drafting and editing internal documents, emails, and marketing copy
- Summarizing meeting notes and publicly available information
- Writing or reviewing code in company repositories
- Brainstorming, research starting points, and format conversion
3. Prohibited without written approval
- Entering client-identifying or client-confidential information
- Entering employee records, payroll data, or health information
- Entering passwords, keys, or security configurations
- Using personal AI accounts for any company work
- Sending AI output to a client, court, or regulator without a
named human reviewing and approving it first
4. Review and logging
- AI-assisted work that leaves the company gets a human review;
the reviewer is accountable for the content
- [Owner/role] maintains the list of approved tools and accounts
- Material decisions supported by AI (pricing, hiring, financial
reporting) are logged: tool, prompt, output, reviewer, date
5. When in doubt
- Ask [owner/role] before pasting. Asking is never a violation.
For most firms this size, the whole cycle is 2–4 weeks of part-time effort, and most of it is conversation rather than paperwork.
The policy is the paper half; the working half is the tool inventory, the business-account setup, and the guardrails that make the rules stick. That’s the first working session in [[AI solutions and intelligent automation]] — and it usually surfaces the riskiest paste before the policy is even final.
]]>A few years ago, a small and medium business (SMB) cyber application was a page of yes/no questions. Today it’s a multi-page attestation, and your answers do three jobs at once: they set your premium, they set your exclusions, and they become evidence if you ever file a claim. An answer you guessed at — “sure, we have multi-factor on everything” — can void coverage at the exact moment you need it, because carriers investigate the attestation after an incident, not before.
Four controls carry most of the weight: multi-factor authentication, endpoint detection, backups, and offboarding. They also happen to track closely with the U.S. Cybersecurity and Infrastructure Security Agency’s (CISA) Cyber Essentials guidance, which is a useful free reference whether or not an insurer is asking.
Multi-factor authentication (MFA) means a second proof of identity beyond the password. The application will ask about it on email, on remote access, on administrator accounts, and increasingly on the backup console itself — because attackers who get in like to delete the backups first.
How it moves the number: for many carriers, “no” here isn’t a surcharge, it’s a declination or a ransomware exclusion. The good news is that MFA is usually the cheapest control on the list — on Microsoft 365 or Google Workspace it’s configuration work, not new spending.
Endpoint detection and response (EDR) watches behavior on laptops and servers — a process encrypting files at 2 a.m., a login from nowhere — and can isolate a machine automatically. That’s different from legacy antivirus, which checks files against a list of known bad ones. Applications now ask for the product by name and what percentage of devices it covers.
How it moves the number: weak answers here tend to show up less in the base premium and more in the fine print — higher retentions (your deductible) and lower ransomware sub-limits.
The application asks three things: do you back up the systems that matter, is at least one copy offline or immutable (meaning the same attacker who encrypted your network can’t encrypt it too), and have you actually tested a restore. A backup that lives on the same network with the same credentials as everything else counts as no. So does a backup that has never been restored — until it’s tested, it’s a hope, not a control.
How it moves the number: tested, separated backups shorten downtime, and downtime is most of what the insurer is pricing.
How quickly are accounts disabled when someone leaves? Are there shared logins? Do former employees or contractors still have live credentials to email, remote access, or the accounting system? Stale accounts are one of the cheapest ways into a network, and carriers know it. For a multi-location retailer or a construction firm with seasonal field staff, this question deserves more attention than it usually gets.
Ranges, because that’s what’s honest: SMB cyber premiums commonly run from the low four figures to the low five figures per year depending on revenue, industry, and limits. The four controls above largely decide which market you shop in. A documented yes on all four puts you in the standard market with competitive quotes. A no — or a “partially,” which carriers read as no — typically means some combination of higher retention, a ransomware sub-limit, an exclusion, or a push into surplus-market pricing that can run a multiple of standard. The premium is the visible cost; the exclusions are the expensive one.
Do this before the broker’s deadline, not the night of.
If the self-audit produced more “partially” than you’d like, closing exactly these four gaps — and producing the documentation that lets you answer the application honestly — is standard scope for [[Managed IT services]]. Bring the application; it makes a very good project plan.
]]>AI is moving into the finance function at small and medium businesses (SMBs) through the side door: proposing general ledger (GL) codes for bank-feed transactions, drafting reconciliations, estimating accruals, writing collections emails. All useful. But finance has a century-old discipline for actions that touch the books — every journal entry carries who, what, when, a source document, and an approval — and AI actions in those same workflows carry none of that by default.
A vendor’s chat history is not an audit trail. It lives on the vendor’s retention schedule, in an account you may not control, in a format you can’t hand to an auditor. Meanwhile, financial records are typically retained for around seven years. If an AI-proposed categorization flows into an entry your auditor questions in year three, “the conversation expired” is not a working answer.
The control frameworks don’t carve out software, either. The Committee of Sponsoring Organizations of the Treadway Commission’s Internal Control — Integrated Framework expects control activities and reliable information regardless of which actor performs a step. An AI proposing entries is a preparer. Preparers generate evidence.
Treat every AI touch of a financial workflow like a journal entry. The mapping is direct:
| Evidence on a journal entry | Equivalent for an AI action |
|---|---|
| Preparer | Staff member who ran it, plus the model and version used |
| Date | Timestamp of the run |
| Amounts and accounts | The output, verbatim — proposed codes, numbers, or draft text |
| Source document | The exact input snapshot: the bank-feed export, the invoice batch |
| Approval | Named reviewer, their decision, and the date |
If you can produce those five fields for any AI-assisted step, you have a control. If you can’t, you have a very fast, very confident preparer working off the books.
None of these questions are exotic — they’re the standard questions asked about any preparer. The only new part is that the preparer is software.
Walking into fieldwork with a register that answers all five is the difference between AI reading as a well-controlled efficiency and AI reading as a scope expansion.
For a typical SMB finance team, standing this up takes 2–4 weeks of part-time effort. Week one is scoping: list every place AI currently touches a financial workflow — the inventory is usually longer than the controller expects. Week two, define the register and the preparer/approver split for the highest-volume touchpoint, which is almost always bank-feed categorization. Weeks three and four, run it live, tune the exception process, and fold the rules into your broader AI use policy so the register’s scope and [[An AI acceptable-use policy your team will actually follow]] agree on what counts as touching the books.
This is the finance-literate side of AI adoption, and it’s where a dual accounting-and-systems background earns its keep. If AI is already drafting entries somewhere in your close, see our [[Finance tech]] — accounting systems and controls that hold up under audit.
]]>You can feel it the first time an agent reads your repo, forms a plan, runs your test suite, and hands you a diff — all from a request you typed where ls used to go. The shell stopped being a dumb pipe to the kernel and started behaving like an operating system in its own right: scheduling work, holding context, remembering what you told it last week, deciding which tools to call. I’ve started calling that composite bashos — not a product you install, but the posture the command line is taking on as artificial intelligence (AI) moves into it.
This is a field guide to that shift, written for people who already live in a terminal. The good news and the bad news are the same sentence: the thing coming for your job is also the best tool you’ve ever been handed. Learning to tell those two apart — and then to ride the one that’s left — is the whole new trade.
A while back I argued that [[Prompts are the new command line]] — that the interface for getting work out of a machine had moved from syntax you memorize to intent you describe. That was the first half of the story. The second half is what the terminal does after it understands you.
An operating system, stripped to its job description, does a handful of things: it schedules work, manages memory, keeps track of context, brokers access to tools and devices, and enforces who is allowed to do what. Look at what a modern terminal agent does and the list is eerily familiar. It schedules a sequence of steps. It manages a context window like a working set, paging facts in and out. It remembers project conventions across sessions. It decides which command-line tool to reach for. It (should) ask before it touches anything dangerous. The shell has quietly acquired the responsibilities of a kernel — except the thing it schedules isn’t CPU time, it’s intent.
Make it concrete. Last year, “rotate the logging config across the fleet and confirm nothing broke” was a morning: Secure Shell (SSH) into box after box, edit files, grep for errors, eyeball the dashboards. The bashos version is one sentence of intent, after which an agent drafts the change, runs it against a staging box, diffs the before-and-after, and reports what moved — and you spend your morning deciding whether it was right, not typing it. The work didn’t vanish. It changed shape, from doing to directing.
This isn’t a metaphor I’m straining to make fit. As of mid-2026 the terminal-agent category is the fastest-moving corner of the developer-tools market, and the field is crowded: Claude Code, Gemini CLI, OpenAI’s Codex CLI, OpenCode, Aider, Warp, Goose, and Amazon Q Developer CLI all run the same core loop — read your project, plan, execute in your shell, show you the result. Microsoft announced an Intelligent Terminal at Build 2026: a separate, opt-in build of Windows Terminal that pipes your shell context to whichever agent you bolt on — Copilot, Claude Code, Codex, Gemini — over a local Agent Client Protocol. And in the research world, projects like AIOS have gone the literal distance and put a large language model where the kernel scheduler used to sit, complete with agent scheduling, memory management, and tool-access control.
Put those together and the trend line is clear. The command line is no longer just a way to issue instructions to an operating system. It’s becoming one.
Here’s the part nobody on a vendor stage will say plainly: the same capability is both the threat and the tool, and there is no version of the future where you get one without the other.
Start with the threat, because pretending it isn’t there ages badly. A large share of traditional systems-administration work is exactly the kind of bounded, well-documented toil that an agent eats for breakfast. Provisioning, log triage, writing the same firewall rule for the hundredth time, turning a ticket into a three-line script: that used to be the moat. The moat is now a one-liner you hand to a process that doesn’t sleep, doesn’t get bored, and costs less per hour than your coffee. Technical skills date faster than they used to, and the specific keystrokes you’re proud of have a shorter shelf life than your laptop.
Now the other face of the same beast. The practitioners who actually fold AI into their workflow get real hours back — the ones that used to vanish into rote work — and demonstrable AI fluency is starting to separate otherwise-identical résumés. Engineering organizations running terminal agents at scale report shipping faster and reclaiming meaningful capacity. The threat and the tool are not two things. They are one thing, viewed from two sides of your own willingness to use it.
That’s what makes the competition your best friend-enemy. You cannot out-type the agent; it’s faster. You cannot out-remember it; it holds the whole repo in context. What you can do — the only durable move — is out-judge it: decide what’s worth doing, catch it when it’s confidently wrong, and own the outcome when it ships. Beating the beast and harnessing the beast turn out to be the same maneuver. You befriend it, you point it, and you stay the one holding the leash.
The old loop was simple and human-bound: you think of a command, you type it, the machine runs it, you read the output, repeat. Every cycle went through your fingers. That ceiling — your typing speed and your recall — was the real constraint on a sysadmin’s throughput for forty years.
The new loop breaks the ceiling by taking your fingers out of the inner cycle. You state an intent. The agent drafts a plan. It executes in a sandbox. It shows you a diff or a dry-run. You review, correct, approve. You own the result. Notice what moved: you are no longer the operator of the machine. You are the orchestrator of something that operates the machine for you.
Which is to say you’ve been promoted into the kernel. Every responsibility an agent operating system has to handle, a human now handles one level up:
That is the literal job spec of an operating-system kernel, now running on you. The phrase that keeps rattling around my head is operating systems built into them — and it cuts both ways. The AI has an operating system built into it. And the professionals who thrive build an operating system into themselves: a disciplined internal model for how to dispatch, constrain, and verify a fleet of tireless, fallible workers. The trade isn’t disappearing. It’s moving up the stack, from the keyboard to the control room.
Enough theory. If bashos is the terrain, here is how to actually work it — the practices that separate people getting real leverage from people generating impressive-looking nonsense at scale.
The instinct is to tool-hop — a new command-line interface (CLI) every week, chasing benchmarks. Resist it. The leverage comes from fluency, and fluency comes from repetition. Pick one capable terminal agent, point it at real work, and stay long enough to learn its failure modes: where it over-edits, where it invents a flag, where it needs a nudge. A tool you know cold beats a marginally better tool you’re always relearning.
The single biggest predictor of whether an agent helps or hurts is what it knows going in. Give it a map. Most agents now read a project file — AGENTS.md, CLAUDE.md, a README, a runbook — on startup, and that file is one of the most valuable things in your repo now. Write down the conventions, the architecture, the do-not-touch list, the commands to build and test. Context engineering has quietly overtaken prompt cleverness as the skill that matters: a plain prompt with great context beats a brilliant prompt with none.
The cardinal discipline is plan, then diff, then commit, with a human between each step on anything that matters. Run agents in a sandbox by default — Codex CLI, for one, isolates execution so it can install packages and run tests without touching your real environment. Dry-run destructive operations. Never let an agent push to production, drop a table, or rm -rf unattended. The cost of reading a diff is seconds; the cost of an unreviewed agent action against prod is your weekend, or your job.
There’s a quiet lesson coming out of teams running these agents in anger: feeding an agent a pile of giant, chatty integrations is often worse than letting it call small, composable command-line tools. The token cost alone is lopsided — a focused CLI call can be a couple of orders of magnitude cheaper than the equivalent fat-protocol round trip — and the behavior is more predictable. The Unix philosophy did not die when the AI showed up; it got a new customer. An agent that pipes grep, jq, gh, and kubectl together runs circles around one drowning in context it can’t use.
The senior engineer’s real value was never the keystrokes — it was the judgment encoded in their muscle memory and their home-directory aliases. Externalize it. Turn a runbook into a prompt. Turn a good prompt into a saved slash-command or a skill. Turn a recurring workflow into a scheduled agent that runs at 6am and leaves you a report. Each step converts something locked in one person’s head into an asset the whole team — and the agents — can run the same way every time. This is the modern Makefile, and it compounds.
A useful mental model: the agent is a brilliant, fast, oddly confident junior who has somehow been handed root. You would not let that person operate without guardrails, and you delegate to them without abdicating to them. Give the agent its own identity, not your god-credentials — the platforms are moving toward exactly this, issuing agents their own scoped identity and audit trail. Least privilege, secrets out of prompts, log everything it does. In a world where everyone has the same models, your security posture is the differentiator that doesn’t commoditize.
An agent will hand you a wrong answer with the same cheerful confidence as a right one. The defense is to make verification cheap and automatic: tests, linters, type-checkers, and continuous integration (CI) are no longer hygiene — they’re the seatbelt that lets you drive fast. The teams getting the most out of agents are, paradoxically, the ones with the strictest automated checks, because strong verification is what makes it safe to delegate aggressively. Trust the beast exactly as far as your test suite can throw it.
The great irony: AI in the terminal makes deep systems knowledge more valuable, not less. You cannot review a plan you don’t understand. You cannot catch a confidently wrong networking change if you don’t know how the network works. The professional who only knew the keystrokes is the one the agent replaces; the one who knows why becomes the indispensable reviewer of last resort. Keep reading man pages. Keep learning how the kernel, the filesystem, and the protocols actually behave. That knowledge is what you trade on now — your edge isn’t speed anymore, it’s correctness.
You don’t master this by reading about it. Pick one agent. Point it at a real repository you already understand — not a toy — and give it a genuine task: write the tests for a module, draft the runbook, refactor the ugly function. Write the AGENTS.md while you’re in there. Then read every diff before you accept it, and notice where it was brilliant and where it lied. Do that for a week and you’ll have a more honest sense of the beast than any blog post — including this one — can give you.
In the spirit of practicing what it preaches, this piece was built the way it describes working. The research — the current state of terminal agents, the Microsoft Intelligent Terminal, the shape of the workforce shift — was gathered by an AI agent fanning out across sources, then checked against more than one of them before any claim made it in. The structure was drafted, argued with, and rewritten. The judgment about what’s true, what’s overstated, and what’s worth saying stayed human. That’s the loop in miniature: let the beast do the fetching and the first draft; keep the deciding for yourself. A few things that made it work, and that generalize:
That’s bashos in one paragraph: the machine got faster, and the part that’s still your job got more important.
The quest was never to beat the beast. It was to become the kind of professional the beast makes more valuable instead of less — the one holding the leash, reading the diff, owning the call. bashos isn’t something you download. It’s something you become.
$ supervise "the beast" &
[1] running
$ # the prompt comes back. what you do with the freedom is the whole job.
The competition really is your best friend-enemy. So make friends — and keep your hand on the leash.
And if you’re working out where terminal agents fit in your own shop — what to hand them, what to gate, and what to keep human — that’s the conversation behind our [[AI solutions and intelligent automation]].
]]>The Model Context Protocol (MCP) is an open standard for connecting AI assistants to outside systems — file shares, databases, business applications. It was originally developed by Anthropic and is now openly published, with the specification and documentation at modelcontextprotocol.io.
The plainest way to think about it: before the Universal Serial Bus (USB), every device needed its own cable and its own port. MCP does for AI-to-system connections what USB did for peripherals — one standard plug instead of a custom cable per pairing.
There are two halves. The assistant side speaks the protocol. On the system side, a small adapter called an MCP server sits in front of each system and exposes a short menu of named operations — “search the policy folder,” “look up ticket status,” “read the AR export” — each with defined inputs and outputs. The assistant can only order off that menu. That constraint is the whole point.
Until recently, wiring an assistant into your file share or ticketing system meant a custom integration — the kind of project that gets quoted in weeks of development time and never gets funded at small and medium business (SMB) scale. A standard changes the economics. Adapters are small and reusable, vendors increasingly ship their own, and the work shifts from building plumbing to deciding permissions — which is where an owner’s attention belongs anyway. For the back-office wiring described below, that’s typically days of configuration and guardrail design rather than a custom development project.
The value isn’t in exotic new systems. It’s in the ones you already run.
Here’s the framing that keeps these projects safe. A language model is probabilistic: the same question can produce two different answers. Your general ledger, your job-costing system, and your ticket queue are deterministic: the same query returns the same record every time. Good architecture keeps the facts in the deterministic systems and the judgment in the model.
MCP enforces that split at the connector. Each tool the server exposes is a defined operation against a system of record — the assistant decides which tool to call and how to phrase the answer, but the number comes from the export and the ticket status comes from the queue. The model can’t invent an operation you didn’t expose. When a wrong answer would cost money, the thing that prevents it is a permission, not a clever prompt. This is the same trust discipline we laid out in [[Prompts are the new command line]], pushed down into the plumbing.
If there’s a copy-paste ritual in your back office that an assistant with two or three tightly scoped connections would end, that’s a well-bounded first project. See how we scope this kind of work in [[AI solutions and intelligent automation]].
]]>One long brittle pipe— a single stage coughs, the whole morning runs to null.
Here is the automation everyone writes first. It is a straight line. It reads like a sentence and it dies like one.
$ fetch | clean | enrich | score | route | notify | log | archive
Eight stages, seven pipes, one direction. It feels efficient because it looks efficient — no branching, no loops, no ceremony, just data falling downhill from left to right. You ship it. It runs beautifully for nine days. On the tenth, enrich times out against a third-party application programming interface (API) at 6 a.m., and because a Unix pipeline is only as alive as its narrowest dead stage, everything downstream of enrich receives an empty stream and dutifully processes nothing. score scores nothing. route routes nothing. notify notifies no one that nothing happened. By the time you look, the whole morning has run cleanly to null and reported success, because exit code 0 is the most dangerous lie in computing.
The straight line is brittle for a reason that has nothing to do with this particular API. It’s brittle because it has no way to correct itself. Data goes in one end and out the other, and nowhere in that geometry is there a path for the output to inform the input. A line is not a system. A line is a hope with stages.
The fix is not more stages. The fix is a shape. And the shape, it turns out, is almost always a triangle — because three is the magic number, and I mean that structurally, not mystically.
Two legs and it tips, four legs rock on uneven floors—three sits dead still.
Bob Dorough sang it in 1973 — a man and a woman had a little baby, yes they did, there were three in the family, that’s a magic number — and a generation learned multiplication from a cartoon that was, underneath the harmony, making a claim about structure. Three is not magic because it’s lucky. Three is magic because it’s the first number that holds.
Watch a three-legged stool on a stone floor. It never wobbles. It cannot wobble, because three points define exactly one plane, and any three points — however uneven the floor — sit flush against the single plane they define. A four-legged chair on the same floor rocks, because four points over-define the plane and the floor gets a vote. This is why surveyors use tripods, why your camera mount has three legs, why the milking stool has survived ten thousand years of furniture innovation unchanged. Three is the minimum that is also the maximum: the fewest supports that guarantee stability, and one more than that buys you nothing but a rock.
Now look at the triangle itself. In structural engineering the triangle is the only rigid polygon. Push on the corner of a square frame and it collapses into a rhombus — the angles give, the shape folds flat. Push on the corner of a triangle and nothing moves, because to change a triangle’s shape you’d have to change the length of a side, and the sides are members under tension and compression, not hinges. This is the entire reason bridges, cranes, roof trusses, transmission towers, and geodesic domes are built from triangles and not squares. The triangle distributes load to its corners and refuses to deform. Squares need diagonal bracing to survive — and a diagonal brace is just a confession that you wanted a triangle all along.
So when I tell you to build automation in threes, I am not invoking the rule of comedy or the three acts of a screenplay, though those rhyme. I am telling you that three is the smallest count of things that produces a structure instead of a pile. Two oscillates. Four wobbles. Three holds load.
Wind dead on the bow— you cannot sail straight; you tack a triangle home.
Here is the part that feels wrong until you’ve lived it: the most efficient route to a goal is often not the straight line at it.
A sailboat cannot sail directly into the wind. Point the bow at the thing you want when the thing you want is upwind, and you stop dead, sails luffing, going nowhere with great conviction. The efficient path to a point you cannot approach head-on is a triangle — you tack, sailing at an angle off the wind on one leg, then crossing to the opposite angle on the next, and the zigzag, which looks like a detour to anyone who’s never held a tiller, gets you there when the straight line gets you nothing. The triangle isn’t the scenic route. The triangle is the only route, and it is faster than the straight line that doesn’t move.
Mathematicians have a name for the deep version of this: the triangle inequality. For any three points, the direct side is never longer than the sum of the other two — d(A,C) ≤ d(A,B) + d(B,C). It sounds like a tautology and it is the foundation of every routing optimizer ever written. It’s why a logistics planner reaches for a milk-run loop — depot to A to B to C and home — instead of driving out and back, out and back, out and back, three separate round trips from the depot. Each leg of the loop is never longer than the detour back through the depot would be, so the loop that touches three points in sequence beats the star that returns to center between each one. Triangulate the route and you stop paying for the trip home you take three times.
And the same geometry runs the wall you plugged this laptop into. The electrical grid does not deliver power as one wire doing its best. It delivers three-phase power: three alternating currents, each offset by 120 degrees — a third of a cycle — so that as one phase troughs, another peaks, and the sum delivers smooth, constant power with no dead spots. One phase pulses. Two phases still leave gaps. Three phases, spaced a third of a circle apart, hand the motor a continuous push and use less copper doing it. Every industrial motor on Earth runs on the discovery that three rotating things, evenly offset, never all rest at once.
That is what a good automation loop is. Not a line — a triangle of three nodes, each handing off to the next, the third feeding back to the first. You already know the shapes, because the disciplines that survived all converged on the same three-node loop and gave it different names:
Notice what each of these has that the straight pipe didn’t: the third node points back at the first. Act changes the world that Sense reads. Learn rewrites what you Build. The triangle closes. That closure is the difference between a system that corrects itself and a sentence that runs to null at 6 a.m. and tells you it succeeded.
#!/usr/bin/env bash
# Not a pipe. A loop with three vertices and a way home.
while true; do
state=$(sense) # read the world
action=$(decide "$state") # choose, given the reading
apply "$action" # change the world
sleep "$INTERVAL" # ...and sense the world you just changed
done
Two nodes — sense and act, no decide — and you get a relay that slams on and off, oscillating, because nothing mediates. Four nodes and you’ve added a vertex that someone will eventually have to explain to a new hire, and which will be the one that’s subtly out of phase. Three nodes hold load.
Mind holds three at most— break the mountain into three stones you can lift now.
A loop needs something to loop over, and this is where most automation dies a second, quieter death: the chunk is the wrong size.
Human working memory holds about three to four items at once — the number has shrunk in the literature since George Miller’s famous “seven, plus or minus two,” and the honest modern figure is closer to four, often three under load. You do not overcome that ceiling by trying harder. You overcome it by chunking: grouping the raw material into a handful of units each small enough to hold whole. A phone number is ten digits you can’t retain and three chunks you can. A goal is the same. “Migrate the platform” is a mountain you cannot lift and cannot even see the top of. “Stand up the new database, dual-write to both for a week, cut reads over” is three stones, and you can pick up the first one today.
Machines have the same constraint wearing different clothes. In [[work & play & dev &: job control for the sleep-deprived]], the lesson was that dev — the deep-work process — only makes progress in long uninterrupted blocks because it needs its whole working set resident and the cache hot; starve it of a contiguous slice and it produces nothing but guilt. Chunking is how you size work to the slice you can actually give it. Too big a chunk and the job can’t fit in one focused block, so it never completes and never checkpoints — it just thrashes, paging your attention to disk. Too small a chunk and you drown in overhead: the cost isn’t the work, it’s the context switch between the pieces, and a thousand tiny pieces means a thousand switches, each taxed.
The right chunk is the one you can carry through the loop exactly once — sense it, decide on it, act on it — before you have to set it down. And the elegant part, the part that closes the loop back to the triangle, is that the best chunking is also in threes. Break the goal into three. Break each of those into three. You descend a tree where every node has three children, and a tree of depth three already has twenty-seven leaves — enough granularity to schedule real work, shallow enough that you can still see the root from the leaf. Divide and conquer is the oldest algorithm we have, and it does not divide into eleven. It halves, or it thirds, and the thirds tend to map better onto the way a goal actually has a beginning, a middle, and a done.
# A goal you can't hold:
deploy_the_whole_thing
# Chunked into a loop you can run, three at a time:
for stone in stand_up_db dual_write cut_over; do
result=$(run_chunk "$stone") || { rollback "$stone"; break; }
checkpoint "$stone" "$result" # set it down before you pick up the next
done
Three stones. Each one small enough to lift, run through the loop once, and set down with a checkpoint — so that when enrich times out at 6 a.m., you lose one stone, not the morning.
Five, seven, then five— the small fast core reads the work, routes it, steps aside.
A haiku is three lines: five syllables, seven, five. It is the smallest poem that still completes a thought — short enough to hold whole in working memory, structured enough to have a shape, and built, of course, on three. The form survived a thousand years for the same reason the milking stool did: it is the minimum that holds. Every epigraph above this paragraph has been one, and you read each of them in a single slice without strain. That is not decoration. That is the chunk size of the human mind, set to verse.
There is a haiku of trade, too — the smallest complete transaction, the three-beat loop at the bottom of all commerce. A request comes in. A decision is made. A response goes out. Read the order, decide the fulfillment, ship the thing. Five-seven-five. Sense, decide, act. It is the same triangle wearing an apron, and for the whole history of business it had a human at the front of it: someone who read what came in, judged what it was, and routed it onward — the clerk, the dispatcher, the desk that triaged the morning’s mail into piles.
That front seat is now an artificial intelligence (AI) core. And here is the actual news, the thing under your brief: it is not the biggest model that takes the front. It’s the smallest fast one.
The pattern has a name in the trade now — the router, or the cascade — and the economics are the triangle inequality applied to compute. You do not send every request to the most powerful, most expensive model you own, any more than you’d drive a separate round trip from the depot for every single package. You put a small, fast, cheap model at the front — call it a Haiku, because that is precisely the role and, as it happens, the name of the model class built for it — and its whole job is the first beat of the loop: read the work, decide what it is, and route it. Most requests are simple, and the fast front-line core handles them whole and ships the answer in one slice. The genuinely hard ones — the cases where the triangle inequality says the detour through heavier compute actually pays — it escalates: hands them up to the heavyweight, the deep reasoner, or out to the human who’s the right one of the three to lift this particular stone. The fast core reads the work, routes it, and steps aside.
# The haiku of trade, with an AI core at the front.
classify=$(haiku "triage: $request") # the fast front-line read — line one
case "$classify" in
simple) haiku "resolve: $request" ;; # ...handles it whole, ships it
hard) opus "resolve: $request" ;; # ...escalates to the heavyweight
human) queue_for_human "$request" ;; # ...or routes to the right person
esac
# Front core fronts. All else follows what it sends.
This is the inversion worth sitting with. The instinct is to put your most capable thing at the front of the operation — the senior engineer reads every ticket, the biggest model sees every prompt, the partner takes every call. It’s backwards, and it’s backwards for a reason you now have the geometry to see. The front of a loop is the sensing node, and sensing wants to be fast, cheap, and constant — three offset phases handing off a smooth signal, not one enormous pulse with dead spots between. You want the heavy capability held in reserve for the chunk that genuinely earns it, the way you hold dev’s deep block for the work that needs the whole cache hot. Put the fast core in front to triage and route, and the expensive capability stops being a bottleneck and becomes an escalation path. The Haiku takes the front. All else follows what it sends.
Which means the entire performance of the system now rides on a thing it never used to: the quality of the routing. When a small fast core sits at the front of the trade and everything downstream follows its read, a bad triage doesn’t fail loudly — it succeeds, confidently, at the wrong thing, and runs your morning to null while reporting exit 0. The clerk who mis-sorts the mail mis-sorts it fast and at scale. So the discipline shifts from doing the work to checking the front — auditing what the router escalates and what it doesn’t, watching the cases it waves through, keeping the human in the loop precisely at the vertex where the fast core decides who lifts the stone. The automation didn’t remove the judgment. It moved it to the front and made it the only thing that matters.
Haiku takes the front; all else follows what it sends— earn what comes behind.
You will keep wanting to build the straight line. It reads so cleanly left to right, and the shape of a sentence is the shape of how we think a task should go: this, then this, then this, then done. But a line has no way home. It cannot correct what it got wrong because nothing in its geometry points backward, and so the first dead stage runs the rest of it to null and tells you it worked.
Three is the magic number, and the magic is structural. So, three things to take with you — because of course there are three:
Build the loop, not the line. Three nodes, the third pointing back at the first. Sense, decide, act, and sense the world you just changed. The triangle is the only shape that holds load, and a loop that closes is the only automation that corrects itself.
Chunk the goal until it fits in one slice. Three stones, each small enough to carry through the loop once and set down with a checkpoint. The right chunk size is the one that survives an interruption without losing the morning. When in doubt, third it.
Put the fast core at the front. The haiku of trade now has an AI core reading the first line — small, fast, constant — routing most of the work whole and escalating only the chunk that earns the heavyweight or the human. That’s the efficient shape. But the front is now the whole game: all else follows what it sends, so audit the read, watch what it waves through, and make sure what comes behind is worth the follow.
The trade has a new clerk at the front desk, and it works in fives and sevens and fives, sorting the morning’s mail faster than any human ever could. For a Denver small or medium business (SMB), that is the difference between two analysts hand-triaging support tickets all morning and a small model routing most of them — often 70–85% — in seconds, freeing your people for the harder fraction that actually needs a human. That’s not the end of your job. That’s the start of a better one — minding the vertex where the fast core decides, because everything downstream is now following a haiku, and a haiku is only as good as its first line.
$ exit 0 # this time, on purpose.
At BASH Consulting we build the automation that holds — loops that correct themselves, goals chunked to a size your team can actually carry, and AI cores placed where they make the system faster instead of where they make the demo flashier. If your pipeline is a straight line quietly running to null at 6 a.m., see how our [[Software development]] work puts the right shape — and the right model — at the front.