How it works

Engines compute. Agents prepare. Brokers decide. The record keeps it.

The architecture of InsightPlacement: deterministic engines for every figure, ten agents on a shared pipeline that reason over the engines’ facts, a grounding check between the model and the reader, prepared decisions capped at ask first, controls in the Rules Studio, and a decision record per placement.

Architecture

Five layers, one direction of trust

Data flows up from the placement’s rows; authority flows down from people.

flowchart TB
  UI["Web app: Home, Renewals, Placement Workspace,
Clients, Carrier appetite, Rules Studio, AI and Agents, copilot"]
  API["InsightPlacement API"]
  ENG["Engines: calendar, exposures, SOV, losses,
readiness, ranking, comparison, diligent effort, quote reader"]
  AG["Ten agents on the shared pipeline"]
  MOD["Model on Amazon Bedrock:
Haiku 5.5 agents, Sonnet 5.5 copilot"]
  GR{{"Grounding check"}}
  RS["Rules Studio:
placement controls"]
  DR[("Decision record and audit")]
  DB[("Postgres: the placement schema")]
  UI --> API --> ENG --> AG
  AG <--> MOD
  AG --> GR --> UI
  API --> RS --> DR
  UI -- "accept, change, reject, ask" --> DR
  ENG --- DB
  DR --- DB

The agent pipeline

Gather, reason, check, prepare

Analyze (or an event such as a new document) runs the agents in order, each as itself at its own level. A step with nothing to do says why and stops.

sequenceDiagram
  participant B as Broker
  participant P as Pipeline
  participant E as Engines
  participant M as Model
  participant D as Decision record
  B->>P: Analyze
  loop ten agents in order
    P->>E: compute for this step
    E-->>P: numbered facts with sources
    P->>M: facts and the step's question
    M-->>P: findings citing fact numbers
    P->>P: grounding check, strip fact markers
    P-->>B: prepared decision at L1 or L2
  end
  P->>D: controls run, verdict
  B->>D: accept, change, reject or ask (signed)

Engines, never the model

Every figure — days, readiness, TIV, loss ratios, scores, premiums, changes — comes from deterministic functions with known-answer tests.

Grounded or discarded

An answer carrying a number not in its facts is thrown away and the engine’s finding stands. Fact markers never reach a reader.

Works with the model off

Switch the model off and every engine and agent still runs; each decision says it stands on the engines.

The placement lifecycle

Seven stages, a calendar, and what is expected by when

1Start

Intake

The placement opens on the 120/90/60/30-day calendar.

2By 120 days

Data collection

Exposures, loss runs, the SOV and the expiring policies.

3By 90 days

Submission

The market-ready package, every gap flagged.

4By 60 days

Marketing

The marketing plan and the outreach to each market.

5Quotes in

Quoting

Quote letters read and compared against the expiring.

6By 30 days

Proposal

The client proposal from the selected quotes.

7Sign-off

Bound

The client’s sign-off, then the bind order.

A placement behind its mark shows on Renewals and Home as “behind the calendar”; the late-loss-runs and late-marketing controls refer it to a lead.

Autonomy

Every action capped at ask first

The level used for an action is the lowest of the agent’s level, the action’s hard cap (L2 for every placement action) and the tenant ceiling (PLACE_AGENTS_MAX_LEVEL, L2 by default). Agreement over answered decisions is measured per agent and action.

The autonomy page: tenant ceiling L2, L3 and L4 locked, and an agent's level per action and line — **Autonomy.** L3 and L4 are locked: what goes to a client, a carrier or a binder is a person’s call.

Rules Studio

Controls as sentences, versioned and tested

Ten placement controls ship as the starter set. A lead drafts a change, tests it against real placements and publishes a new version; every hit on the decision record names the version that fired.

Published placement controls in the Rules Studio, each with its condition, effect, state and version — **Placement controls.** Warn, refer to a role, or block the bind.

The platform and the suite

Built on the Insight platform, connected to the broker suite

Package	What it does in InsightPlacement
`insight_agents`	Agent pipeline, run store, registry, autonomy service, traces (Lense)
`insight_diligence`	The data room, the `commercial_placement` readiness playbook, the agents’ model kit, facts, grounding and citation stripping
`insight_decisions`	The decision record, hits and signed answers
`insight_rules`, `insight_broker`	Rules Studio and placement controls; the broker roster; the binder check
`insight_assist`	The copilot: tool-calling, scoped, grounded answers
`insight_home`	Home for account executive, placement broker and account manager
`insight_comms`	Sends through a provider; the dry-run provider in the demo
`insight_identity`	Sign-in, organisations, roles and tokens

Connections, and their status

Product	What it adds	Status in the current release
InsightPulse	Company profile and news for each client, dated and attributed	Read when a Pulse endpoint is configured; an illustrative stand-in otherwise
InsightAdvocate	The client’s loss trend and open claims, briefed to the placement team before renewal	Prepared in InsightAdvocate and sent as a recorded dry run
InsightXtract	Quote letters read into structured quotes	A deterministic stand-in reader in the demo
InsightProofing	The issued policy checked against what was bound	A sibling product; the selected quotes and bind order are its reference
InsightUW / InsightCW	The carrier-side underwriting and claims workbenches on the same platform	Not required; a submission is a document any carrier can read