How we are designing agent deployments at SOVRAS

When a company wants an agent to prepare a quote, the conversation is usually the easy part. The work is in checking the right stock, applying the commercial terms, verifying the customer details and knowing when an approval has to be requested.

All of that happens behind a request that, for the user, should be simple.

At SOVRAS we are building the platform around this kind of operation. And from engineering there is one question that shapes how we design the product: how much of each implementation can we reuse when the next customer arrives?

First you have to understand how the company works

A company can hand us its procedures, its documentation and access to its systems. That is a good starting point, but we still need to understand how decisions get made while the work is happening.

For example:

• What happens when there is not enough stock?
• Can a sales rep authorize a different price?
• Which system confirms that the order was registered?
• Who picks the operation back up when an exception shows up?

These are details that vary quite a lot between companies, even when they want to automate exactly the same process.

That is why our onboarding combines the product with engineering work.

Agent Studio is where agents are defined, knowledge is added, tools are configured and rules are set. But when there are complex integrations or processes that need more precision, our engineers work directly with the customer to model them, connect the systems and prepare the tests.

Part of the work happens on the platform and part of it happens in technical meetings, process reviews and validations with the people who know the operation.

What we build once and what we adapt

Think of two distributors. One calculates prices according to each customer's contract. The other uses a commercial price list and requires authorization when the discount goes over a certain percentage.

Both need agents that can prepare quotes, but their rules are different.

It would make no sense to build two complete systems to manage those cases, record the actions, add approvals or supervise the results.

That infrastructure belongs to SOVRAS.

Agent Studio is where the agents around each operation get configured. VARO coordinates the work between agents, systems and people, holding the state of the case as it moves forward.

What we adapt is the tools, the sources of information, the policies and the conditions under which an operation can continue.

This also calls for decisions during every implementation. Some needs are met by configuring existing components. Others require building an integration or extending a capability of the platform.

Our job is to tell the difference and to keep each particularity from ending up as isolated code that nobody else can use.

The hard cases are part of the deployment too

A demo can show a quote that starts and finishes without trouble. In production we have to account for what happens when something fails.

• An ERP can stop responding after receiving a request.
• An approval can sit pending for hours.
• An operation can break off after updating one of several systems.

Those situations need defined handling: checking what was executed, preserving the state and deciding how to continue without repeating actions that already took effect.

That is why we work with execution rules, supervision and scenario testing before handing more autonomy to the agents. VARO Arena is part of that preparation.

What happens after the deployment matters as well. The errors we find and the changes in behavior have to be able to turn into new tests and improvements for the agents that come next.

Making every implementation leave something reusable

When an integration comes up again, it makes sense to turn it into a component another customer can use. The same goes for a validation, an approval policy or a test scenario we used to resolve by hand.

That is part of how we are building SOVRAS.

We want the teams inside each company to be able to configure progressively more operations from the platform, while our engineers concentrate on the systems, the exceptions and the technical decisions that need closer work.

It does not mean every customer will have an identical onboarding. A simple implementation and an operation that involves several internal systems will still call for different effort.

What matters is that the work also makes the product better.

If we have to build the same solution from scratch for three different customers, there is something we should have brought into the platform earlier.