BOE

Bag of Engines

Micro engines

35+ micro engines for the decisions your product keeps making.

Scoring, eligibility, risk, anomaly detection, matching, forecasting, and a growing list beside them. Give an engine your inputs and your policy; it returns an answer and the reasoning that produced it, in a form an auditor can read as it stands.

Agents are probabilistic. The decisions under them should not be.

Built for what calls it now

01 / The caller

An agent calls it like any other tool.

Built for the agentic era first: a call shape a model can use without a wrapper around it, and latency low enough to sit inside a reasoning loop rather than beside one. The services already in production call the same engine, unchanged.

02 / The division

A model reasons. It should not be the thing that decides.

A model is probabilistic by design and slow by comparison. That is right for language and wrong for eligibility, exposure and price. An engine takes those off the model’s path and returns them in milliseconds, so the agent keeps the judgement and gives up the guessing.

03 / The guarantee

Same inputs, same answer. Every time.

One set of inputs against one policy version returns one answer, today and a year from today. That is what makes a decision defensible after the fact, and it is the one thing a model cannot promise about its own output.

The engine index

35+ engines · six families


  • Scoring

    Turn a set of attributes into a number you can defend in a meeting. Weights and cutoffs live in policy, versioned and readable.

    returns → value · band · the factors that moved it

  • Eligibility

    Decide who qualifies against rules that change without warning. Old decisions stay explainable under the policy that was live when they were made.

    returns → verdict · the rule that decided it

  • Risk

    Quantify exposure before you commit to it, with the assumptions recorded beside the number and legible to anyone who has to sign off on them.

    returns → exposure · drivers · assumptions

  • Anomaly detection

    Flag what stands out from the pattern. Every flag arrives with the deviation that triggered it and the baseline it was measured against.

    returns → flag · deviation · baseline used

  • Matching

    Pair records, people, or supply and demand, with a confidence you can set a threshold against and a reason for every pairing.

    returns → pairs · confidence · fields that agreed

  • Forecasting

    Project the next N periods with intervals attached, so the plan built on top of it knows how much to trust it.

    returns → path · intervals · window and method

The full index runs to 35+ engines and keeps growing.

Browse all engines

Where BOE came from

Off by cents.

BOE started as one skill inside something else. The work was an integrations scaffold for an AWS-native integration platform, built to simplify a portfolio of separate integration systems and take cost out across it. Part of that design was a cost skill: tell me what this integration runs at varying volumes.

It was well received. Five times in a row before the demo, memory cleared between runs, the numbers came out exact. Then the calculation comparing the integration systems against the native solution came back off by cents. It also took too long to get there.

Nobody else noticed. Everyone was happy with the results. Kamau was not.

He had started his career at FICO working with the BizTalk rules engine and Blaze Advisor, and had spent the years since collecting and studying rules engines and the algorithms under them, including the work of Charles Forgy, an advisor at FICO. The off-by-cents problem sent him back to all of it.

With LLMs good enough to move at the speed of the study, he built a pricing engine to end the problem. Then forward chaining. Backward chaining. Bayesian. Sequential. Constraint. Utility and MCDM. Twenty engines by January 1st, 2026. Today, 35+ and counting.

Every one of them leaves the trail that would have caught the original discrepancy on the first run.

The plain audit trail

Every decision leaves something you can read.

A record of what went in, where each value came from, which version of the policy was live, which factors moved the outcome, and what came out. The engineer on call, the analyst and the regulator all read the same thing.

  1. 01Lineage: every input carries the source it came from and the transform it passed through.
  2. 02Reproducible: replay the inputs and the same answer comes back.
  3. 03Versioned: the policy that decided is pinned to the decision.
  4. 04Portable: exportable in a form your systems already accept.

Specimen record

Sample values

engine
eligibility
decided_at
2026-09-04T14:22:07Z
policy
tier2_underwriting · v14
subject
sub_8Q41KD7M
inputs
tenure_months=31 · region=NE · exposure=B
lineage
crm.accounts → normalize_v3 → ledger.exposure
rules_fired
min_tenure_12 · region_allowed
outcome
qualified
trace
tr_01JC7F3K9WQZ

What comes with every engine

Seven of a longer list


Scalability

Throughput is a configuration question.

Reliability

Retries, timeouts and idempotency already agreed on.

Durability

Decisions survive the process that made them.

Observability

Every call emits the same shape, so dashboards are cheap.

Security

Least privilege and data handling set at the boundary.

Auditability

The trail ships with the answer, every time.

Lineage

Every input traced to the source it came from and the transform it passed through.

Practices and patterns

The list covers more than quality attributes. Alongside them sit known best practices and modern patterns, already applied by the time an engine reaches you.

Which decision would you hand off first?

Bring the one your team keeps re-deriving. If one of the 35+ engines covers it, the next step is a call shape and a policy.