MARCUS at work. Prepared for review.
MARCUS prepares documents, finds answers in company records, and stages work for human review at B:Side Capital, an SBA 504 and CDFI lender.
These are B:Side’s reported results from a founder-affiliated deployment: Christopher Myers leads both organizations. The figures are first-party, not independently audited.
- Client
- B:Side Capital
- Period
- June–August 2026
- Updated
- 2026-09-10
- Evidence
- Workflow studies + audit log
What changed for the team.
Estimated staff preparation hours returned during June–August 2026, calculated from B:Side’s initial workflow studies. This is operating capacity, not measured payroll savings.
Reported weekly use by week six, across a staff of 45 employees. The percentage is rounded; an exact active-user count is not published.
Borrower identifiers reported as sent to outside models during the measurement window. Filtering is required; detection is not guaranteed to be perfect.
Of consequential actions approved by a person during the reported window, before sending, filing, posting, or paying.
Reporting period: June–August 2026. B:Side reports these results for the stated period. Preparation hours are estimates calculated from its initial workflow studies; operational activity is reported from its audit log. Returned capacity is not measured payroll savings. Annualized equivalents are not measured annual results.
Founder-affiliated, first-party reporting. Read the measurement definitions, sources, and limits
Less assembly.
More room for judgment.
SBA 504 loan package assembly is the clearest example of the change at B:Side. MARCUS prepares the package; the lender reviews it and retains responsibility for the decision.
The comparison describes the shift from manual assembly to reviewing prepared work. It does not claim that a loan is approved or funded in the review time shown.
Read the measurement notes- Start with the loan records
The source records and documents for the package.
- MARCUS assembles the package
The preparation work is brought together for review.
- The lender reviews and decides
Staff check the prepared work. Lending decisions remain with people.
Simplified view of B:Side’s reported workflow. Assembly time and human review time describe different stages, not total elapsed turnaround.
Prepare the work.
Keep the decision.
MARCUS connects the records, communication tools, and books B:Side already uses. The machine prepares; a person reviews consequential work before it moves.
- Prepare safely. Requests and records pass through the privacy filter to a local model or selected external reasoning on filtered text.
- Bring the evidence. Prepared work includes sources and exceptions for the reviewer.
- A person decides. Approve, send back, or escalate. Consequential action follows approval.
Why it was built in this order
B:Side already had the data, the front door, and the books — process documents by the hundred, a team living in Slack, systems of record for loans and accounting. What they didn’t have was a way to ask any of it a question, or a way to hand it the preparation work, without borrower data leaving a controlled environment.
So we built the seven things below, in order, each one proven on real files before the next shipped. The highest-exposure work — funds movement, distressed assets — was deliberately built last, behind the strictest gates, once trust was established.
How to read the results.
Use these figures to understand one deployment. A comparable result in your business needs its own baseline, scope, and measurement.
Download the public evidence brief · Build your own workflow measurement log
- Reporting period
- June–August 2026. Measurement context clarified by Christopher Myers on 2026-09-10. The period is identified by month; exact day boundaries are not specified.
- Source and attribution
- B:Side reports these results. The preparation-hours estimate comes from its initial workflow studies; operational activity is reported from its audit log. Christopher Myers leads both organizations. This is first-party reporting, not an independent audit.
- Preparation time
- The hours figure estimates returned preparation capacity. The detailed calculation worksheet, sample sizes, and treatment of human review and corrections are not published in this summary. It should not be treated as measured net labor savings, reduced payroll, or an observed annual result.
- Adoption and review
- Weekly adoption measures use by week six across 45 employees. The percentage is rounded; an exact active-user count is not published. Human approval covers consequential actions during the reported period.
- Data handling
- Source documents are processed locally. Selected tasks can use external reasoning on filtered text. The external-identifier figure describes reported exposure during this window; a mandatory filter does not guarantee perfect detection. Read the deployment controls and limitations.
- Comparison with your business
- Include review time, exceptions, operating costs, and the useful work returned capacity would support. Discuss the evidence and assumptions before using these figures in an investment decision.
Explore the work behind the figures.
Open a chapter for the delivered components, reported measurements, and operating boundaries.
01Prepare from company recordsServer · filtering · knowledge
B:Side owns the hardware used for local model processing and can maintain or replace the model independently of the workflow.
One box, in a locked room, with B:Side’s name on the invoice.
We specified and configured a server to run open-source models locally. The hardware was purchased in B:Side’s name at cost, with zero markup. This gave the team ownership of the local processing environment.
We have already swapped the local model once for a newer one — better answers, same workflows, nobody retrained. Once the machine is yours and the filter is in place, the model is just a part you replace.
Uptime since commissioning in February 2026 — one planned maintenance window, zero unplanned outages.
Local model calls processed on B:Side’s hardware during the reported period. Selected external-model tasks are a separate processing route.
Hardware markup. The server was bought at cost in the client’s name.
Mid-flight model upgrade, completed in an evening, with zero workflow changes for staff.
Ownership: B:Side owns the server. Hardware, configuration, and ongoing care are separate parts of evaluating a comparable deployment.
Staff needed a controlled route for using models with company information, rather than choosing a public chatbot independently.
A privacy filter before model processing.
Prompts and attachments pass through a filter that detects and removes supported personal identifiers. Tasks can then route to a local model or, by B:Side’s choice, to a commercial model on filtered text. Mandatory filtering establishes the route; it does not guarantee every identifier was detected.
We don’t take the filter’s accuracy on faith. A seeded set of documents carrying known, planted identifiers runs against it every month — and every miss becomes a new test case.
Routine work can use the local model while selected tasks use external reasoning on filtered text. External processing remains a data-handling decision. The recall result below describes the seeded test set, not a guarantee of perfect detection in every production document.
Of prompts and attachments cleared the filter before reaching any model. No bypass path exists in the architecture.
Personal identifiers detected and stripped — names, SSNs, account numbers — across ~38,000 documents processed.
Detection recall on the monthly seeded test set. This measures known test identifiers, not every possible identifier in production.
PII incidents reported since the filter went live.
Data boundary: Review which tasks can use external models, what text they receive, and how filtering is tested before choosing a deployment.
The company remembers more than any one person in it. This is where that memory went so it could be asked questions.
Everything B:Side knows, in one place, in a form the machine can use.
Structured loan records on one side; process documents, correspondence, and policies on the other — joined so a single question can cross both. A lender has loans and findings the way a contractor has jobs and change orders: same shape, different nouns.
B:Side defined the core records, events, document sources, and access rules in a knowledge-base questionnaire. Those answers guided the tables, indexes, ingestion pipeline, and read tools. The reported delivery time below starts from the completed questionnaire.
From completed questionnaire to a queryable knowledge base — generated from the intake, not hand-designed.
Process documents ingested, joined with thousands of loan records and a decade of institutional correspondence.
Questions asked by staff by month three — the questions that used to wait for whoever just knows.
Of answers delivered with a citation to the source document or record. The rest say they do not know, and escalate to a person.
Dependencies: The knowledge base depends on useful source records and defined access rules. Start by identifying which questions it must answer and which sources are authoritative.
02Deliver into the team’s daySlack · workspace · accounting
The best interface is the one their people were already staring at.
No new app. No new login. The first question came eleven minutes after go-live.
MARCUS works inside B:Side’s Slack, where staff already communicate. Prepared work and approvals arrive in the same channels, reducing the need to switch tools to review a task.
Each division received a short introduction to the workflow. Familiar tools reduced interface training; staff still needed to understand what the system prepared, what to check, and when to escalate.
From go-live to the first real staff question, before the introductory session.
Weekly active adoption by week six, across all seven divisions — including the skeptics.
Of all MARCUS interactions happen in Slack — finished work delivered to the channel where the team already works.
Adoption: Put prepared work where staff already work, then measure whether they use it and how often it needs correction.
The books already knew the answer. This is what it took to ask.
Reconciliation prepared. Invoices staged. Receivables chased. Nothing posted until a person approves.
The accounting connector let MARCUS see the books: month-end reconciliation arrives prepared with exceptions flagged, vendor invoices arrive pre-coded with the source attached, aging receivables get follow-ups drafted the day they cross the threshold. A person approves every entry before anything posts — that is not a limitation, it is the design.
The connector prepares work against B:Side’s existing accounting records. The review remains with the person responsible for the books, with sources and exceptions available before anything posts.
Reported before-and-after comparisons. The review-time figures describe the human review step, not total elapsed turnaround or a measured percentage reduction.
Vendor invoices staged during the reported period, each pre-coded with source attached — every one approved by a person before posting.
Reconciliation mismatches surfaced automatically before month-end — found by the system, decided by a person.
Improvement in average days-to-collect on fee invoices, from follow-ups drafted the day an invoice ages past threshold.
Integration: A comparable build starts with your accounting and operating systems. The build catalog describes capabilities that can be included in a scoped engagement.
03Keep decisions accountableTesting · approval · escalation
Anyone can demo an AI. We show ours failing, on purpose, on a schedule.
Test the exceptions before they reach the team.
Nightly tests exercise B:Side’s configuration against eligibility edge cases, malformed documents, planted identifiers, and adversarial prompts. The results appear on a dashboard the team can review. The reported regression count below describes issues caught during the measurement period; tests cannot establish that every possible failure has been covered.
An append-only, hash-chained log records system actions. It helps the team trace an action to its trigger, source, and approval, and check recorded entries for changes.
Automated assertions run nightly against the production configuration — plus a monthly deliberate failure drill.
Regressions caught by the harness before any staff member encountered them. Zero found by staff first.
Entries on the tamper-evident audit log — every action traceable to its trigger, its approver, and its source document.
Of the test harness consists of reusable assertion-running code; the remainder consists of client-specific test cases.
After launch: A test suite and audit trail ship with the build. Optional Managed Services adds ongoing monitoring and maintenance of the agreed systems.
MARCUS prepares the work. People decide.
Consequential sending, filing, posting, and payments wait for human approval. Routine routing and escalation follow the agreed rules.
MARCUS never decides eligibility, credit, or price — those numbers come from systems, never from memory. Across the measurement window, every consequential action passed through a human approval: approve, send back, or escalate.
Escalation is automatic, including for anything that has waited too long. Silence never means yes.
The work moves forward — approved on first presentation, most within the hour.
Returned with comments. Every send-back becomes training signal and, where it generalizes, a new test case.
Handed to the right person, plus every request that waited too long. Escalation is automatic; silence never means yes.
Bring the workflow you want to improve. We’ll discuss the systems involved, data handling, human review, and the scope a useful build would need. Start with a free 30-minute assessment; we reply to requests within 24 hours.
The guarantee: If a scoped workflow is not live in your operation within 90 days, we keep building at no charge until it is.
The credit: Your audit fee can be credited toward a sprint signed within 60 days, up to 25% of the sprint price.
A fixed price, quoted in writing before we start, and a straight answer within 24 hours.
— Christopher Myers, Founder