Summary: Regulated operations rarely run under one rule set. Different states impose different disclosure obligations, different counterparties demand different documentation, and different products carry different regulatory treatment. Policy profiles solve the problem most platforms force you to solve badly: they keep one workflow and vary the rules where they must vary. This post defines the concept and shows why it is the difference between scaling a workflow and multiplying a liability.
The multi-regime problem
Take a commercial lender operating in 14 states, servicing loans for 30 institutional counterparties, across four product lines. The underwriting workflow is the same everywhere: ingest the package, extract the financials, evaluate the credit policy, route exceptions, document the decision.
The rules are not the same anywhere. One state requires an extra disclosure. One counterparty demands appraisals under a stricter standard. One product line triggers different regulatory treatment above a threshold.
Most platforms force one of two bad answers:
- Duplicate the workflow. Fourteen copies, or fifty, each edited independently, each drifting from the others. Within a year no compliance officer can attest to what any copy actually enforces.
- Branch inside the workflow. One workflow with nested conditionals encoding every regime. It runs, and it becomes unauditable: the rules for one jurisdiction are smeared across a hundred branch conditions.
What a policy profile is
A policy profile keeps the workflow singular and makes the variation explicit. The workflow defines the baseline: the policy logic that applies in every context. Profiles define the deltas:
- A counterparty profile encodes that institution’s stricter documentation standards.
- A jurisdiction profile encodes a state’s disclosure obligations.
- A product profile encodes the regulatory treatment of that product line.
Profiles can inherit baseline rules unchanged, adjust a threshold, replace a rule entirely, or suppress one that does not apply. The result: same workflow, different profiles, no duplication, and the differences between regimes are readable as a short list of explicit variations instead of an archaeology project.
Why auditors care
The audit question is never “what does your policy say today.” It is “what rule was in effect for this decision, then.” Profiles make the answer a recorded fact: every decision captures the exact profile that governed it, not just a version number. Six months later, a rerun or backtest executes against that original policy snapshot, not whatever the current configuration happens to be.
That pairs with the rest of the governance stack: plain-English policies the business writes, versioning with rollback, and a why-trail linking each outcome to its policy, data, and evidence. Profiles extend that discipline across regimes.
What this looks like in practice
On MightyBot, profiles are part of the policy engine: the workflow compiles once, and the applicable profile resolves at execution time based on the case: which state, which counterparty, which product. Operations teams onboard a new counterparty by writing a profile, not by cloning a workflow. Compliance reviews a diff, not a second system.
The scaling math is the point. Without profiles, regimes multiply workflows: 14 states times 4 products is 56 artifacts to maintain and attest. With profiles, it is one workflow and a set of named, versioned variations. That is the difference between an automation program that compounds and one that collapses under its own copies.
For how the workflow itself comes to exist, see What Is an Agent Compiler?; for the buyer’s view of platforms that can and cannot do this, the regulated-industries platform comparison covers the field.
