What we build, and the controls around each one.
Four use cases, each built with the same method as every engagement: a written boundary, what counts as done agreed before the build, and a person approving consequential actions. Each one shows who it suits, what goes in, what comes out, the controls and the offer it maps to.
Order, invoice and price-letter intake
For distributors and manufacturers on NetSuite, Business Central, Acumatica or Prophet 21. A person approves every proposal before anything is written back.
Growing companies · Mid-marketRescue and test an agent stuck in pilot
Test the agent against your systems first, then finish it to a written boundary.
Mid-market · EnterpriseA knowledge analyst inside Microsoft Teams
Answers from the sources you permit, with each source logged. The pattern Chainfore built as Auxee for PreScouter.
Mid-market · EnterpriseRolling out Claude, ChatGPT or Copilot
Usage policies, permissions and training, so a team uses the tools within agreed rules.
Growing companies · Mid-marketOrder, invoice and supplier price-letter intake
For distributors and manufacturers on NetSuite, Business Central, Acumatica or Prophet 21. Documents that arrive by email become proposals in your ERP. A person reviews and approves each one before anything is written back.
- Who it suits
- Distributors and manufacturers, from growing companies to mid-market, running NetSuite, Business Central, Acumatica or Prophet 21. Owners, operations directors and controllers whose teams re-key the same documents into the ERP.
- What goes in
- Purchase orders, supplier invoices and supplier price letters as they arrive by email, in PDF or spreadsheet form. Read access to the item master, customers, suppliers and open purchase orders.
- What comes out
- A proposed entry for each document: a sales order, an invoice matched to its purchase order and goods receipt, or a price update matched to the item it changes. Each proposal shows the line it came from and any check it failed, and waits in a review screen.
- Controls
- A person reviews and approves each proposal before anything is written back to the ERP.
- Approval is bound to the exact entry. A changed entry is blocked.
- Supplier documents are treated as data, not instruction.
- A retry cannot create a duplicate entry.
- The result is read back from the ERP. A false completion claim fails the check.
- Maps to
- 01 Workflow architecture and baseline to decide and agree what counts as done. 02 Assured workflow engineering to build the first document type. 04 Reliability operations to keep it dependable as suppliers change their formats.
- Related work
- Falconic, our own product in development, applies the same pattern to supplier price changes: it reads price-increase notices, matches each line to your item master, calculates the margin impact and recommends a reprice. Nothing is written back to your ERP until you approve it. Falconic
Illustrative trace: a supplier price letter
- AgentReads a supplier price letter from the purchasing inbox.Retrieved content is treated as data, not instruction.
- AgentMatches each line to an item in the item master.Lines that do not match are shown to a person, not guessed.
- ModelProposes a new cost and a reprice for each matched item, with the margin impact.The model proposes. It does not decide alone.
- ApproverApproves the exact changes.Approval is bound to parameters and expiry. A changed entry is blocked.
- WorkflowWrites the update to the ERP as a durable, retryable step.An idempotency key means an injected timeout cannot duplicate the write.
- VerifierReads the new prices back from the ERP.Read-back of the authoritative system. A false completion claim fails the check.
A reference example, not a customer deployment or a performance claim.
Rescue and test an AI agent stuck in pilot
An agent that works in a demonstration but has not been trusted in production. We test it against your systems first, then finish it to a written boundary.
- Who it suits
- CTOs, Heads of AI, product leads and AI platform leads at mid-market companies, enterprises and software companies, with an agent in pilot and a decision to make about expanding it. The agent can be built in-house or by Chainfore.
- What goes in
- The agent as it stands, a test environment for the systems it acts on, a set of task cases you have reviewed, and the expansion decision in front of you.
- What comes out
- Outcome tests against the authoritative system state.
- Permission and denied-action tests, including cross-tenant checks.
- A regression suite with repeated-trial reporting.
- A trajectory review of a sample of runs.
- A reproducible evidence pack and a remediation backlog, ranked by severity.
- If you go ahead, the fixes built to a written boundary, with recovery paths, a runbook, an acceptance report and a handover.
- Controls
- The seven failure tests on How you can check us, run against the authoritative system state rather than the agent’s own report. Autonomy is granted in stages: offline, shadow, supervised, limited. Where independence matters, assessment is delivered separately from implementation.
- Maps to
- 03 Agent release assurance first. Then 02 Assured workflow engineering to finish it to a written boundary. 04 Reliability operations once it is live.
- Related work
- The seven failure tests we run before any agent is trusted with more. How you can check us
A knowledge and market-intelligence analyst inside Microsoft Teams
An analyst your team asks questions in Microsoft Teams, answering from the sources you permit. This is the pattern Chainfore built as Auxee for PreScouter. The rows below describe how we scope the use case, not the internals of any client system.
- Who it suits
- Strategy, market-intelligence and knowledge-management teams at mid-market companies and enterprises, and the research consultancies that serve them.
- What goes in
- The internal and licensed sources the analyst may use, the questions your team asks, and who may see which source.
- What comes out
- An analyst inside Microsoft Teams that answers from permitted sources and logs the sources behind each answer, with an operations runbook and an acceptance report against the questions agreed at the start.
- Controls
- Permission-aware context: the analyst uses only sources the person asking may see.
- Retrieved content is treated as data, not instruction, so a document cannot redirect the analyst.
- Provenance logging for each answer.
- Deployment in your cloud, in a managed tenant or on your private network, with controlled supplier access.
- No training or product improvement on your data unless you explicitly authorise it.
- Maps to
- 01 Workflow architecture and baseline to agree sources, permissions and what counts as a good answer. 02 Assured workflow engineering to build it. 04 Reliability operations to keep it dependable as models and sources change. 03 Agent release assurance if you already have an analyst in pilot.
- Related work
- Auxee for PreScouter: an AI market-intelligence analyst, live in production inside Microsoft Teams, built on Activepieces. Client stories
Rolling out Claude, ChatGPT or Copilot to a team
Your team already has the tools, or is about to. We set the rules for using them, configure the permissions and train people on the work they do.
- Who it suits
- Owners and operations managers at growing companies, and COOs, CIOs and HR or learning leads at mid-market companies that have bought seats and want them used well, within agreed rules.
- What goes in
- The tool you use or have chosen, the roles in the team and the work each one does, the data the team handles and what must not leave it, and who administers the workspace.
- What comes out
- A usage policy written for your roles and your data: what each tool may be used for, and what it may not.
- Permissions and connector settings configured in the workspace, so each person reaches only what their role needs.
- Shared workflows built into the workspace for the tasks your team repeats.
- Training by role, on the team’s own tasks.
- A named owner on your side for the policy, and internal champions who keep it going.
- Controls
- The model provider’s data handling, retention and deletion terms are checked and written down before rollout.
- Actions with consequences, such as sending, paying or changing records, stay under human approval.
- A change to the tools, models or permissions triggers a review of the policy.
- Maps to
- Scoped in its own written proposal, starting from the data and access review in 01 Workflow architecture and baseline, then the policy, the rollout plan and training. Shared workflows that connect to your systems are built under 02 Assured workflow engineering. 04 Reliability operations keeps them dependable as the tools change.
- Related work
- The six layers of control we agree in every contract, including training and retention. Security
Tell us what you want built.
Describe the process, the systems involved and what failure costs. We will respond with a proposed first step.