Building AI agents: from process to sales-call briefing

An AI agent is an application in which a language model selects the next steps and tool calls within an assignment. It processes the results and decides whether it needs more information or can complete the task.

For our sales call, the agent might find a reference to a new location on the customer's website. It then reads the original announcement, checks its timing and searches the internal context for relevant material about collaboration across locations. The next source it needs becomes clear as the work progresses.

The overall process remains defined. Within each activity, the agent decides which sources and tools it needs. For a first implementation, this freedom can be clearly bounded: it may investigate further, but it must submit the agreed briefing for review.

We build these parts as an interconnected system: the assignment determines the process, which determines the context and tools required. Instructions connect these foundations with the agent’s decisions. Review then shows where improvements are needed. If the briefing omits the current product status, for example, we check whether the source was outdated, retrieval failed or the agent overlooked information it had received. This tells us which part to change.

Before configuring an agent environment, describe the task so that another person could take it on. In our example: prepare an initial meeting by understanding the concern and developing no more than three well-founded discussion points.

The intended output is a briefing of no more than 500 words. It covers the reason for the meeting, relevant customer information, possible opportunities, specific questions and a suggested next step. Sources and the detailed comparison go in an appendix. This makes it possible to assess whether the agent has completed its assignment.

The inputs are the company name, an unambiguous domain, the meeting date, participants and their professional roles, the sales stage and any existing contact notes. An unclear company identity must be resolved before research begins. A missing contact history can be flagged as a gap in the output.

Sales remains responsible for the meeting. The agent prepares the briefing; the person conducting the call reviews it. This division belongs in the process model because it determines where automated work ends and how corrections feed back into the process.

At NEXTHORIZN, we place meeting preparation within the core Lead-to-Offer process. For this article, we develop it as a distinct subprocess. In PULSE, we first describe the purpose, inputs, outputs and participating roles. The BPMN view then makes the sequence and handoffs visible.

The process has seven activities: clarify the assignment → research the customer → add relationship history → retrieve NEXTHORIZN context → establish fit → draft the briefing → review the briefing. In the model, the agent handles research and preparation; sales handles the assignment and final review. Technical execution by an agent does not change business accountability.

Each activity produces an outcome that can be checked. Research yields a customer profile with sources. Adding contact history establishes the confirmed concern and previous agreements. Only then is the connection to our own offering developed. Review feedback returns to the activity concerned.

In PULSE, the context associated with an activity can be examined. For “Establish fit”, that context would look like this:

The model directly informs the implementation: it shows which information is needed at each stage and who can assess the outcome. The agent environment must then implement the process technically. A process model and linked systems alone do not execute tool calls.

Our agent brings together three perspectives: the public picture of the customer, the existing relationship and our own business context. Each serves a different purpose, and its origin should remain identifiable.

Web research describes the company's activities, services, locations and recent developments. CRM records and conversation notes add what the contact has actually raised and what has already been agreed.

In our design, PULSE provides the foundation for the internal perspective. Strategy and value propositions explain which tasks and target customers our offering addresses. Process descriptions supply workflows, roles and relationships. Maintained knowledge sources add product details, requirements and suitable materials.

For this preparation, we select four types of material: the relevant portfolio and current product status, the customer tasks addressed, suitable process relationships and the requirements of the current sales stage. Our example concerns an initial meeting about team handoffs. The agent therefore mainly needs knowledge about process steps, roles and the information associated with them.

Context is selected for each activity. Once the customer research is complete, it becomes clearer which internal sources are needed. The instructions define how the agent selects those sources and when it retrieves more information. For every discussion point, the product description supporting it remains traceable.

We also need to distinguish our own processes from the customer's possible processes. Our Lead-to-Offer process determines the preparation and meeting objective. How project handoffs actually work at the agency group will only become clear in the conversation. An internal process description can suggest questions, but it cannot establish that unknown reality.

Each activity now tells us which technical capability the agent needs. Choose an agent environment that supports tool calls and can return their results to the model. A first prototype can use a single agent with saved instructions and a manual start.

Finding and reading are separate research capabilities. The agent might search for service pages and recent company announcements. It then opens relevant pages to check statements in context.

In our example, an announcement points to an additional location. The agent needs to establish whether its opening is planned or has already happened. A job posting might provide clues about tasks or applications in use. Whether these apply across the entire company remains open.

Internal access can use MCP if the configured interface makes the required PULSE content available. MCP defines the technical exchange between the application, context sources and tools. Source selection and the substantive comparison are implemented in the agent application.

Test each connection separately. Can the page reader retrieve a complete company announcement? Does the CRM connection find the right note? Does the PULSE connection return the required product description and its origin? An approved document extract can replace a missing connector in the prototype. This lets you assess whether the business task works before completing every integration.

For every tool call, describe its purpose, inputs and outputs clearly. This helps the agent distinguish between finding a source, reading its content and retrieving an internal product description. The runtime also limits access and research scope. Public search queries use public company information; confidential contact notes are evaluated internally.

The process model describes the work from a business perspective. The instructions define how the agent performs it: the required sequence, where it may investigate independently and when it must ask a question or return an incomplete result.

The decisive step in our model is “Establish fit”. We use a fixed chain:

Customer signal → potentially affected process → evidenced offering → benefit hypothesis → discussion question.

This turns the operations lead's message into a specific discussion point. Repeated searching for information is an explicitly stated concern. Project handoffs are the process to investigate. PULSE can connect process steps with roles and relevant knowledge. The hypothesis is that these relationships could help people find the information they need at a handoff.

That leads to the question: “Could you show us a handoff that currently involves a lot of searching or follow-up questions?” The answer would help establish whether the proposed connection holds and which information is actually missing.

The location announcement can suggest a second discussion point. On its own, however, it does not establish difficulties in collaboration. The briefing therefore shows whether a point comes from a customer statement or from an assumption that still needs checking. Every proposed offering connection also needs an internal source describing the relevant capability.

A first set of instructions can summarise these rules:

The specific meeting details are supplied at each start. The application executes permitted tool calls, returns their results to the model and records which sources were used. The agent continues until the agreed output is ready, a question needs answering or the configured limit has been reached.

Read access and briefing output are sufficient for this task. Automatically booking a meeting or contacting the customer would be an additional process activity with its own rules and permissions.

The first briefing shows whether the components work together. Assess everyday reliability using known cases and expectations defined in advance. For each case, specify which information the briefing must contain and which statements the available sources would not support.

Choose an initial contact without a history, a new enquiry following an earlier rejection and a customer request that only matches a planned feature. In the first case, the missing history must remain visible. In the second, the agent must account for the change over time. In the third, the planned feature must not be presented as currently available.

Then review the result against the process model. Does the research concern the right company? Does it reflect the actual concern? Do the internal sources support the product statements? Will the questions elicit information needed for the next step? If something is wrong, you can improve the activity concerned.

The handoff to sales is also part of the test. The reviewer must be able to see the basis for each discussion point. For our example, the preparation should lead to an opening along these lines:

Measure preparation time, including corrections, and collect feedback after the meeting. A useful question or an early misunderstanding caught tells you more about the briefing's value than its length. Use these observations to improve research, context selection or the working instructions.

You can start your own first agent in the same way: choose a bounded activity from a familiar process. Describe the outcome, connect the required information and provide the necessary tools. PULSE makes the business relationships visible, giving the agent a foundation for its assignment and context.