The agent should not need an engineering degree

At Monocept, I worked on explaining technically complex insurance workflows to people whose job was to sell insurance, not develop an additional interest in software architecture.

My audience included insurance agents and sales teams who were not necessarily comfortable with technology. They needed to understand how a system could help them onboard a customer, manage information and produce the required documents.

They did not need a guided tour of everything happening behind the interface. There was a customer waiting.

Starting where the user started

I wanted to begin with the task, not the technology.

How do I enter the customer’s information? What happens to it next? Do I need to type it again? How do I generate the PDF? What do I need to check before moving on?

These were the questions I wanted the communication to answer.

The underlying work involved turning forms into digital journeys, reusing customer information across documents, pre-filling paperwork and supporting electronic signatures. My role was to make those capabilities understandable in terms of the work agents were trying to complete.

“Enter the information once and use it across the required documents” gave someone a practical idea of the benefit. A description beginning with “seamless orchestration” might require a second document to explain the first.

Two kinds of agent, one potential misunderstanding

Agentic AI added another layer to the explanation.

In insurance, “agent” already had a perfectly serviceable meaning. Now there was a software agent as well. One was trying to help a customer; the other needed explaining to the first.

I worked to make the distinction clear without turning it into a vocabulary lesson. What could the system do? What did the person still need to do? How did one step lead to the next?

I wanted the explanation to follow the workflow rather than the engineering diagram. Someone learning a new process should not have to mentally rearrange the material before they could use it.

Plain language was not a concession

I did not see a lack of technical familiarity as a lack of expertise.

An insurance agent could understand the customer, the product and the sales conversation without knowing how information moved between systems. My job was to connect the new technology to that existing knowledge—not make people feel they had arrived insufficiently qualified for their own work.

That meant explaining unfamiliar ideas through familiar tasks, making the sequence clear and giving technical detail a reason to be there.

I wanted people to understand what they could do with the software, rather than merely accept that it was sophisticated.

Making the next step clear

The purpose of my work was not to make a complex system sound simple. It was to make using it easier to understand.

There is a difference. Calling something intuitive does not tell anyone where to click. Announcing that a process is automated does not explain what information someone must provide before the automation has anything useful to do.

At Monocept, I worked in that space between engineering capability and everyday use.

I wanted agents and sales teams to see how the technology related to a customer conversation, a completed form or a document ready for the next step.

They did not need to leave impressed by the explanation.

They needed to know what to do next.