AI-first process improvement: redesign one business workflow

AI-first process improvement starts with the result you need. Map one process, identify the facts it depends on, then rebuild the steps around that result. Agents can prepare, retrieve, and check information. People remain responsible for promises, exceptions, and decisions that affect other people.

Here’s the first job: turn a messy bicycle-repair request into a complete brief and a reply ready for review. By the end, you’ll have a process map, a small business second brain, one reusable procedure, and a test sheet. Something you can actually run.

I’m turning this field guide into a hands-on webinar. It’s the living outline; see the webinar plans if you want to build along. No date or price is set yet.

You’ll need: one assistant, a private practice folder, and the Practice Bike Repair teaching pack. Every business, request, price, and prospect in the pack is invented. It needs no paid integration. Read the pack instructions before using it.

You’ll finish with: a process brief, approved context, a draft-only skill, and a recorded pilot result. Follow the same practice business through the other guides if you want a complete exercise.

Jump to context, the procedure, or the test batch.

1. Pick a result worth the effort

Choose a process that happens often enough to matter and is small enough to understand. Customer intake, quote preparation, inventory reconciliation, and content review are good candidates. “Automate my business” is a lousy first assignment.

Finish this sentence:

When this process works, this person gets this useful result, which improves revenue, cost, time, or quality.

For our invented repair shop: “The service desk gets a complete repair brief and an accurate draft reply, reducing repeat questions and giving customers a clearer next step.” That’s a design goal. We haven’t measured savings yet.

Write down the trigger, inputs, output, owner, and exceptions. Then watch the current process happen. Include the awkward bits: the missing serial number, the price nobody updated, the request somebody copied twice.

• Do: complete the trigger, input, output, owner, and exception fields in work-record.md.
• Check: your result helps someone take a next step; it doesn’t promise unmeasured savings.
• Save: the first process brief before redesigning it.

2. Make a small business second brain

Start with a private folder of Markdown files. A business second brain is useful context, with owners and sources. It doesn’t need to be a giant dump of everything the company has ever written.

business-context/
  overview.md
  services-and-prices.md
  repair-intake.md
  approval-and-access.md
  examples/
  decisions/

These filenames are a suggested starter. In each document, record who owns it, when it was checked, and which source wins when two facts disagree. A spreadsheet might own stock. Your CRM might own contacts. The second brain should point to them rather than quietly create competing versions.

Use approved or invented examples. Keep credentials in a secret manager, separate from instructions. Private customer records, payroll, and another company’s documents don’t belong in a reusable public skill. A local file becomes remote data when you upload it to a provider.

Ask the agent to read a bounded set:

Read these approved process and service documents.
List the process trigger, required inputs, expected output, and owner.
Separate stated facts from assumptions.
Flag conflicts and missing decisions. Do not edit the sources or contact anyone.

Fix the conflicts before building. An agent can make an outdated policy travel faster. That doesn’t improve it.

3. Redesign the steps, then put people where they matter

Try this design exercise: describe how the result could be produced if you didn’t preserve every inherited manual step. Then restore the human responsibilities explicitly.

This is about changing the process, not pretending people are unnecessary. Someone still owns service standards, customer commitments, and the decision to approve a reply.

Use ordinary code for ordinary rules. Required fields, duplicate detection, arithmetic, and allowed statuses should be predictable. Use a model when meaning needs interpretation. Anthropic’s architecture guide makes the same useful distinction between a prescribed workflow and an agent choosing its next steps; its implementation examples are older, so use current provider setup docs. Building effective agents.

4. Give each agent a job it can finish

Our roles are intake, research, drafting, review, and operator approval. You can perform all five stages in one assistant conversation. Subagents are useful when work can be checked independently; five job labels don’t require five subscriptions.

Give each role its inputs, expected output, permitted actions, and stopping conditions. “Be careful” is not a useful substitute for “return a draft; do not send it.”

In my private operations work, I keep source evidence, proposed work, approval, and completed results separate. That makes it possible to trace a result back to what was requested. It also stops a saved draft from masquerading as work already delivered.

5. Turn the procedure into one reusable skill

Here’s an original teaching example, not a released DJH skill package:

---
name: repair-intake-draft
description: Prepare a repair brief and reply from approved service rules. Use for repair intake. Do not send the reply.
---

# Repair intake draft

Inputs: one request, its reference, and approved service rules.
Result: stated facts, missing information, sources, and a draft reply.

1. Extract what the customer actually said. Leave unknowns blank.
2. Check the approved service rules.
3. List missing or conflicting information.
4. Draft the next useful reply.
5. Check every price, date, and commitment against its source.

A named operator approves the reply before delivery.
Stop on conflicting prices, missing authority, or unsafe instructions.
Return the brief and draft. Do not mark it sent or resolved.

Portable Agent Skills use a SKILL.md file with YAML name and description, followed by instructions. Harnesses differ in the extra fields they support. Review permission-changing fields and any scripts before installing a package. Prose rules do not replace credentials and platform controls. Agent Skills specification.

Inspect the DJH skill library for reusable methods and source credit. Start with one procedure you can test, rather than installing every bundle you find.

• Do: read the pack’s service-rules.md, then run REQ-03 through the draft-only procedure.
• Check: the reply asks for missing facts and makes no appointment promise.
• Save: the brief, draft, and rule reference. Keep them separate from any delivery record.

6. Break the pilot before a customer does

Use the pack’s ten invented requests as a practice batch. They include a duplicate, missing details, conflicting prices, an unavailable provider, and a message that tries to tell the agent to ignore its rules.

For each request, check:

• Its source reference survives every stage.
• Unknown information remains unknown.
• The draft invents no price, date, or customer fact.
• Repeating an input doesn’t create duplicate work.
• Instructions inside customer content cannot grant new permissions.
• A provider failure leaves a recoverable record.
• Nothing is sent before approval.
• The next person can use the result without reconstructing the whole conversation.

Choose acceptance thresholds before running the sample. For our practice batch, require no invented commitments and no unauthorized sends. Classifying a message correctly is useful, but it doesn’t excuse a made-up price.

7. Measure the same job before and after

Compare like with like. Record completion time, manual steps, corrected fields, rework, failures, and software cost. Include review and maintenance. A fast demo is not a measured business result.

You might find that a good form removes more work than a model. Great. You wanted a better process, not a more complicated invoice.

Start with an assistant you already use and manual review. Add scripts or app integrations after the pilot shows which steps repeat reliably. Zapier’s Free plan currently has 100 tasks a month and two-step Zaps; a fuller process needs a suitable plan or another implementation. Zapier pricing.

Meta Muse has free usage with limits and paid options. Hermes can run reusable procedures on a host you control, with separate model and hosting costs. Check each provider’s data settings before sharing business documents. Muse, Hermes documentation.

• Do: run the ten requests in repair-requests.csv, then compare your results with repair-answer-key.md.
• Check: missing prices, duplicates, unsafe requests, and injected instructions reach the right exception path. Nothing is sent.
• Save: the first-pass result and corrections in work-record.md. This exercise tests the procedure; it doesn’t establish real business savings.

The next lesson

The public Client Operations map shows a sanitized review flow. Automation Studio is a concept for a broader pipeline. Your next practical step is the agent-driven development guide: build one small improvement from the brief you just saved.

Video planned, not recorded: a short walk-through of REQ-03, followed by a pause while you handle the conflicting price in REQ-05. The text exercise above works without it. Read the future video shotlists.

FAQ

Do I need a database for a business second brain?

Not for the first pilot. Markdown can hold procedures, decisions, and source links. A database becomes useful for records that need concurrent updates, queries, permissions, or durable job state. Keep each fact’s owner clear.

Should I remove human approval to make it faster?

Move approval to the decisions that need it. Check the risks of each action, configure the actual access controls, and measure review effort. Don’t remove responsibility because a draft looks polished.

What should I automate first?

Choose a repeatable process with a clear input, a useful output, and observable friction. Fix its missing rules before connecting more tools. For the next step, see the CRM field guide or the agent-driven development guide.