Start where the work arrives: email
Almost every agency workflow begins in an inbox. Certificate requests, endorsement changes, new submissions, loss runs from carriers and renewal quotes all arrive as emails with attachments. An agent that can read a shared mailbox, classify each message and prepare the next step delivers value before it writes a single field into your agency management system.
Email-first is also the safest way to begin. The agent drafts and a person acts, so nothing changes in the system of record until a CSR has looked at it. Once the drafts are reliable, you can decide which steps deserve a direct connection to the AMS, and that decision is much easier with a few weeks of real data on volumes and error rates.
A typical email-first setup reads a shared mailbox such as service@ or certs@ in Microsoft 365 or Google Workspace. Each new message is classified by request type, matched to an insured where possible and given a draft response or document. Staff see the drafts in a queue or as replies waiting in the mailbox. Requests the agent cannot classify, or that mention a claim, go straight to a person with a short summary attached.
The options for reaching your AMS
There are four broad ways an agent can work with Applied Epic, Vertafore AMS360 or Sagitta, HawkSoft, EZLynx or QQCatalyst. Which ones are available to you depends on your vendor's programs, your edition and your contract, so treat this as a map of options to ask about, not a statement of what any product supports.
Options typically include the ones in the table below, and many agencies end up with a mix. A certificate workflow might read policy data through a supported interface and still leave the final release to a CSR inside the AMS, while a renewal comparison is simply attached to the client record as a document.
Remember that carrier data already flows into many management systems through download, often via IVANS. If policy data reaches your AMS by download, the agent can usually rely on it rather than re-reading policy PDFs, and you avoid two sources of truth.
| Approach | How it works | Good for | Watch for |
|---|---|---|---|
| Email-first, person keys | Agent reads email and documents, prepares drafts, staff enter results in the AMS | Starting fast with no system access | Keying remains; savings come from preparation |
| Document drop | Agent produces files or structured data that staff or a supported import attach to the client record | Comparisons, summaries, ACORD drafts | Check what your AMS can import and in which format |
| Vendor API or partner integration | Agent reads and writes through an interface the AMS vendor provides | High-volume lookups and updates | Access may need vendor approval, fees or a partner agreement |
| Screen automation (RPA) | Software operates the AMS screens as a user would | Systems with no other route | Breaks when screens change; needs monitoring |
Data access: give the agent the least it needs
Treat an AI agent like a new employee with a narrow job description. If it prepares certificates, it needs to read policies, endorsements and holders for commercial clients. It does not need write access to accounting, and it probably does not need personal lines records at all. Ask for a dedicated service account with its own credentials so its activity can be told apart from staff activity.
Think about where documents go. MVRs, loss runs and applications contain personal data. The agent should run under business terms that rule out training on your data, preferably inside your own Microsoft 365 or cloud tenant or a dedicated environment. Redaction during testing is sensible: a pilot can run on documents with names and policy numbers masked.
Credentials deserve the same care. Store them in a secrets vault, rotate them on a schedule and make sure you can switch the agent off in one step if something looks wrong. When a staff member leaves you remove their access the same day, and the agent's account should be just as easy to revoke.
Logging: what a reviewer should be able to see
Every action the agent takes should leave a record a non-technical reviewer can read. For a certificate, that means the original email, the insured and policies matched, the holder record used, the draft produced, who approved it and when. For a comparison, it means each extracted value with its source page.
Logs earn their keep when something goes wrong. If a client says a certificate was wrong, you want to find out in minutes whether the agent misread the request, matched the wrong policy, or produced a correct draft that a person then changed. Without the log, the conversation becomes guesswork.
Keep the agent's notes in the AMS activity history as well as in its own log. Your staff already look there when a client calls, and an entry such as 'certificate drafted by agent, released by J. Ortiz' tells them what happened without opening another system.
What to ask any vendor
Whether you are talking to your AMS vendor about built-in AI, a software product or a services firm like ours, these questions separate a working integration from a slide.
- Which of our workflows can you show running on documents like ours, not a demo dataset?
- How exactly will you connect to our AMS edition, and does that route need vendor approval or extra fees?
- What access does the agent need, and can it run under its own service account?
- Where is our data processed and stored, and is any of it used to train models?
- What does the log show for each action, and how long is it kept?
- What happens when our AMS vendor releases an update?
- Who reviews outputs before anything reaches a client or a carrier?
- How will we measure staff hours saved, including review time?
The limits of integration
Integration does not make an agent's judgment better. A perfectly connected agent can still misread a handwritten driver list or match a request to the wrong of two similar insureds. Writing directly into policy records without review should come late, if at all, and only for narrow updates your team has watched it get right many times. Coverage decisions stay with licensed staff regardless of how the plumbing works.
Starting small with integration
Begin with one workflow, email-first, and measure it. Collect a few weeks of drafts and corrections. Then decide whether a direct connection to the AMS is worth the cost and approval effort for that workflow, based on how much keying remains.
Our five-day AI Workflow Sprint starts the same way: a prototype on your redacted emails and documents, no system access required, and a written assessment of the connection route for your AMS before any build is quoted. That order keeps integration decisions grounded in your real volumes.
Common questions
Do we need API access to our AMS to start?
No. Many useful workflows begin with email and documents alone, with staff entering the results. API or partner access becomes worth pursuing once you know which steps carry enough volume to justify it.
Is screen automation a bad idea?
It can be the only route for some systems. It needs monitoring, because a screen layout change can break it, so it suits stable, high-volume steps where the alternative is manual keying.
Can the agent work with carrier portals too?
Sometimes. Portals vary by carrier, and some terms of use restrict automation. A common pattern is for the agent to prepare a clean submission package that staff upload, and to automate only where the carrier allows it.
Sources
Submission and quote intake
An AI agent that pulls applicant data from applications, loss runs and email, fills the submission once and writes the follow-up for missing information.
How it worksA working prototype on your own documents for $2,500. Full refund if we do not find 10 staff hours a week.
Start a sprint