What Off-the-Shelf AI Misses About How an MGA Actually Processes Submissions
Generic AI extracts data; MGAs need complete files routed by business rules.
Off-the-shelf AI misses MGA submission processing because it treats reading documents as the job, when reading is only the beginning. A managing general agent needs the scattered evidence brought together in a complete, auditable file that follows its business rules and goes to the right underwriter.
Why MGA submission intake is structurally different from the document-processing problem generic AI is built to solve
A broker email arrives with a scanned ACORD form, a loss run in a carrier-specific format, and a statement-of-values spreadsheet whose column headers do not quite agree with anyone else’s. These belong to one risk and must become one underwriting-ready record before risk evaluation can begin. More information may come by fax, in scanned attachments, or in notes from a phone call.
A chatbot, copilot, or horizontal document extractor is generally designed to process a document against a prompt. It has no native concept of the submission package or of the relationship between information spread across its files. The MGA still needs someone to reconcile the pieces, establish what is missing, and decide where the record goes next.
How ACORD forms produce unstructured data even when brokers follow the rules
ACORD forms standardize the form itself. They arrive scanned, partially completed, annotated by hand, and in mixed revisions, before supplemental applications or non-standard attachments enter the picture. Missing fields and contradictions are normal conditions when a package has passed through several hands. Clean-form accuracy tests leave much of that work unexamined.
Brokers submit the material they have, so the MGA cannot make predictable inputs a condition of processing. XPT Specialty’s Dan Rieden described the mismatch in Vertafore’s July 2026 announcement. “Historically, submissions have required standardization through rigid templates, which does not reflect the way business is actually received.” A tool that succeeds on complete ACORD forms may still struggle with the exceptions that consume the intake team’s time.
What line-of-business and state-by-state rules add on top of the data problem
Even a perfectly extracted record has another gate to pass. Before routing, the MGA must check it against appetite criteria, line-of-business rules, and state-specific eligibility requirements. What qualifies in one state may be ineligible in another, while a risk that fits one line may be excluded from another.
Notch’s MGA case study describes business rules, eligibility logic, appetite criteria, and routing rules that varied by state, line of business, and submission type. Routing consequently depended on more than the documents received. Completeness, appetite match, state, line, and priority score all helped determine which underwriter or queue received the submission. Generic extraction can supply the inputs to that process, but it cannot supply business rules it has never been given. Someone who understands those rules must encode them so the system applies them deterministically.
Why delegated authority makes traceability a non-negotiable requirement generic tools ignore
An MGA writing under delegated authority answers to someone beyond its own management. The capacity provider whose pen it holds can audit the bordereau and the submission records behind it. That relationship creates a requirement for evidence about how data was produced. A carrier that handles its own intake answers to its own governance structure, while the MGA must also answer to the capacity provider.
A confidence score cannot meet that obligation by itself. It expresses certainty, but it does not point to the clause, line, or document supporting a value. Field-level citations provide that connection and make an AI-generated record auditable. Kolena’s platform description says that every run has a full audit trail, with the specific clause, line, or figure that backed each data point. With a generic tool that lacks this audit trail, the MGA cannot show the required link between an extracted value and its source, even when the output looks convincing.
Where generic AI actually stalls is exception handling, not extraction accuracy
The production test begins when a submission is incomplete, contradictory, or presented in an unfamiliar format. When a required field is missing, the next step could be human review, a broker follow-up, or a search for the answer elsewhere in the package. Choosing among them requires workflow logic. The system must know what the line of business requires before it can distinguish an acceptable omission from a submission that cannot advance. Reporting what is present is not the same as recognizing what is absent.
Vertafore’s Velocity AI Submission Processing Agent, launched July 8, 2026, addresses this gap by evaluating completeness, flagging missing information, and generating follow-up requests to brokers. A different exception arises when the named insured on an ACORD form does not match the name on the loss run. Both names may have been extracted correctly. What that disagreement means for the combined record remains unresolved.
If the team still has to resolve exceptions by hand, submissions wait while it works through the queue. Volume spikes make that delay more consequential because a faster market can quote first. Domain knowledge decides how the exception is resolved and whether the submission moves forward.
The cost of slow intake that never shows up on a staffing budget
The cost of that waiting is not confined to the people processing the queue. For every submission, someone must do the manual triage, from opening the email and downloading attachments to checking appetite, entering data, and routing the file. Underwriters doing this work are not evaluating risk or building broker relationships. A staffing budget records the expense of their time, but not the opportunities displaced by it.
The market that responds first often captures the opportunity, and brokers direct future submissions toward markets that responded last time. Slower intake can therefore transfer attractive risks to faster competitors while weakening the flow of future business.
Growth adds pressure to that feedback loop. The notes describe a US MGA market worth hundreds of billions, growing at more than double the rate of the overall P&C market. Submission volumes are rising faster than teams can absorb them manually. Adding intake work to an underwriter’s day leaves less room for the decisions and relationships that distinguish the business.
What purpose-built MGA intake AI does that generic tools structurally cannot
Purpose-built intake treats the package as the unit of work. It unifies the broker email, ACORD form, loss run, and supplemental application into one record, extracting entities across the files and resolving conflicts between them. In its work for a 10-line, 25-state MGA, Notch brought data from the different input channels into a structured submission record. Missing or conflicting information was flagged with source-linked evidence pointing to the document or email behind the issue. That gives the person resolving an exception both the problem and its supporting evidence.
Encoded rules then govern how that record proceeds. Under appetite criteria, eligibility logic, and state-specific requirements, the record advances, receives priority, needs clarification, or enters a particular underwriting queue. The system applies the MGA’s rules, while targeted broker requests address gaps that would otherwise stop the process. This combines extraction with a defined next action rather than delivering another file for someone to sort out.
The handoff into the policy administration system is equally important. Structured data must flow straight into the PAS so that no one has to enter the data again after intake. When a point solution extracts information but leaves validation or policy checking separate, the MGA still has to join those steps into one workflow. SANSA’s embedded-engineer model addresses this implementation layer by placing an engineer within the workflow to encode the MGA’s logic and integration requirements, rather than treating a configured tool as the finished system.
Why the underwriting governance objection to AI intake is legitimate and how it is properly bounded
Practitioners are right to distinguish software that prepares a submission from software that makes an underwriting decision. Reading, structuring, completing, and routing a file remove clerical work, while assessing risk substitutes for professional judgment if handed to the system. Those are different assignments with different consequences. An intake project becomes a governance problem when its scope quietly crosses that boundary.
Kolena states the intended division plainly. “AI handles intake, clearance, and file preparation. The underwriting authority and risk decision stay entirely with your underwriters.” The Velocity agent likewise prepares information for underwriting review. Building that boundary into the system does more to keep underwriting authority with people than a broad promise that they will stay involved.
The practical first step is an AI governance usage policy documenting what the MGA is comfortable allowing AI to do and what remains outside its scope. That policy gives the implementation a boundary to follow. Hallucination and over-confidence risks are substantially lower for extraction, rule-checking, and routing than for open-ended underwriting recommendations. Lower risk does not mean no risk. The legitimate concern therefore points toward disciplined scope, source evidence, and defined authority, rather than toward retaining manual intake by default.
How an embedded AI engineer encodes MGA-specific logic that no off-the-shelf configuration can replicate
The remaining gap is primarily one of implementation. A generic vendor cannot ship an MGA’s particular appetite criteria, state-specific eligibility rules, exception paths, and PAS integration requirements out of the box. Encoding them requires someone who understands both the business logic and the AI tooling. Neither half is sufficient alone. The forward-deployed engineer model brings that work into the MGA’s workflow, where the system can be built around the actual sequence of intake decisions.
SANSA’s engagement model starts by diagnosing the highest-leverage bottleneck in two weeks, then building a production-ready system around it and staying embedded as its value compounds. Intake fits that model because the first bottleneck is identifiable and the initial system can be scoped for delivery in weeks. For a smaller MGA that cannot hire a senior AI engineer or afford a six-month implementation cycle, an embedded engineer is another way to get the work done. Work starts shipping in days, and the engagement can scale down when the cycle ends.
Once structured, source-linked, rule-checked records reach underwriters without manual triage, the business can build more capabilities on that base. Those may include appetite-based prioritization, automated declination under defined rules, bordereau generation, or a service line the team could not staff before. Each depends on the MGA’s own book, appetite, and the limits set by its governance.
