A customer’s AI agent may prepare a renewal proposal, create a service request, reconcile invoices or submit an order for review. In each case, the platform must be able to connect the action to a customer organisation, a defined authority and a recorded outcome.

That requirement reaches across the product’s identity model, permission structure, workflow logic and audit records. The relevant architecture is not an “agent integration” sitting beside the application.

It is a control layer that allows software to use established business capabilities under conditions the platform can administer and explain.

Every controlled agent action should have four connected records: the agent, the delegation, the approval path and the resulting execution.

1 The agent record

A user account identifies a person. Client credentials identify an application. An agent operating for a customer needs its own identity within the platform, because the product has to recognise the technical actor separately from the person or team that enabled access.

That record should connect the agent to the relevant customer tenant, business unit where applicable, client application, authentication method and delegating user or service. It should also retain the version or configuration that was active when the action occurred.

Version information is operationally important. An agent may later use different tools, receive different instructions or connect to further data sources. When a customer asks why a request was created or how a record was amended, the platform should be able to identify the configuration that carried out the work at that point in time.

This becomes particularly useful when one customer operates several agents. A procurement agent preparing renewal material, a finance agent reviewing exceptions and a support agent assembling cases may all work within the same tenant, while requiring different permissions and different routes through the product.

The customer should be able to register, review, suspend and retire each of those agents independently. Suspending a reconciliation agent should not interfere with employee access, another customer integration or a separate agent working in a different area of the product.

2 The delegation record

The agent identity establishes who is acting. The delegation record establishes what authority that agent is using.

Human roles commonly describe an ongoing position in an organisation. A procurement manager may have broad access because their work spans suppliers, contracts, approval routes and commercial conditions. An agent will usually operate within a narrower remit tied to a particular task or workflow.

Consider a contract-renewal agent. A procurement manager may authorise it to retrieve contracts approaching renewal, gather current supplier data and prepare draft proposals. The delegation could apply only to one subsidiary, specified contract categories and a defined period during the renewal cycle. It may permit preparation of a proposal while reserving final submission for a responsible user.

A well-defined delegation covers the workflow, available actions, relevant data, time limit, commercial thresholds, approval requirements and revocation rights. It gives the platform a practical basis for evaluating each requested action in its current context.

The permission is not “act as this user.” It is “perform these actions for this customer, within this workflow, subject to these conditions.”

That distinction allows the product to handle situations that look similar at a technical level but have different business consequences.

An agent may be allowed to prepare one renewal request, while another requires a different route because the supplier has a restricted status, the contract value exceeds a threshold or the customer’s policy requires additional review.

The delegation should also support reliable handling of repeated requests. An agent may retry after a timeout or interrupted connection. The platform needs to recognise whether it has received a new instruction, an attempt to continue a pending workflow or a repeat of an action already completed.

3 The approval record

Agent-operated workflows benefit from a clear distinction between preparation and commitment.

A renewal agent can assemble contract terms, account activity, supplier history and pricing information before producing a proposal. The responsible user should review that defined proposal within the product, with the relevant supporting records available at the point of approval.

The platform can then confirm that the underlying conditions remain current before executing the approved action. A revised contract value, changed account status, expired approval or updated policy may return the proposal to review.

Approval should attach to a specific business outcome. It should not function as a general instruction for an agent to continue working.

This gives customers room to decide how far an agent may progress a workflow. Creating an internal task or a support case may be suitable for direct execution. Contract amendments, payment instructions, pricing changes and external communications may require approval within the established product workflow.

The approval path should therefore use the same states, validation rules and customer-specific controls that already govern the process when a person completes it through the application. The agent may prepare the work and bring it to the right point in the workflow. The platform remains responsible for deciding when the outcome becomes binding.

4 The execution record

An agent request can involve several parts of the platform before it produces a business result. It may retrieve records, calculate eligibility, create a draft, enter an approval route and update one or more related entities.

The execution record connects those events into a traceable account of what happened.

Each workflow run should have a reference that follows the action from the initial request to the resulting state change. That record should link the agent and its configuration, the customer tenant, the active delegation, the requested action, relevant source records, policy results, approval event, platform services involved and final outcome.

A customer support team investigating an unexpected order should be able to establish:

Which agent acted, for which customer, under which authority, through which workflow and with what result.

The same record is useful to engineering and product teams. It shows where requests stop, which approvals create repeated exceptions and where the product needs more precise service responses or clearer workflow states for machine-operated use.

The evidence should remain proportionate to the task. Source-record references, structured policy outcomes and versioned drafts often provide the required operational record without keeping unrestricted copies of all information available to the agent. This is particularly relevant where workflows involve personal data or commercially sensitive customer information. GDPR Article 25 requires data protection by design and by default, including measures that support data minimisation and appropriate safeguards.

Where the control layer sits

The control layer belongs between the agent request and the business services that produce the outcome.

An order agent may request eligible products, customer-specific pricing and order validation. The product services should continue to determine stock availability, credit conditions, tax treatment, delivery options and approval requirements. The agent receives a structured result from the application rather than reproducing those rules in its own configuration.

The core platform remains the source of business decisions. The agent requests recognised capabilities. The application evaluates those requests against current customer data, record state and workflow rules.

This matters particularly in established B2B software, where commercially relevant logic is distributed across .NET services, internal APIs, databases, workflow engines and third-party integrations. Clear service boundaries allow teams to expose useful capabilities to agents while keeping the existing application responsible for the underlying rules.

The same work usually benefits conventional integrations and internal tools. More precise service contracts, explicit workflow states and clearer outcomes make the platform easier to work with across channels.

Choosing the first workflow

The strongest initial use case is usually one where the agent prepares a defined outcome that enters an existing review process. It gives the business useful operational support while exercising the identity, delegation, approval and audit model in a manageable scope.

Contract-renewal preparation, invoice reconciliation, account summaries, exception handling, support-case drafting and order preparation are common examples. Each has an identifiable customer owner, a known business result and a workflow that can be connected to existing product rules.

The first delivery should establish a reusable model for agent identity, delegated authority, workflow state, request handling, auditability and customer administration. Later use cases can then adopt the same structure instead of introducing separate permission and audit arrangements for every new agent capability.

Compliance implications

The EU AI Act does not define AI agents as a separate legal category. Agents may fall within the wider definitions of AI systems or general-purpose AI models, with obligations determined by the system’s role, intended use and risk classification. From 2 August 2026, an agent that qualifies as a high-risk AI system is subject to the relevant Chapter III requirements, while transparency rules may apply where it interacts with natural persons or generates content.

For B2B platform teams, the immediate work is more concrete than the legal label. The product needs to establish authority, apply customer and workflow controls, limit data access appropriately and retain evidence of the actions completed through an agent.

Where Blocshop fits

Blocshop works with B2B software companies that want to introduce agent-operated workflows into established products while retaining the business rules, customer controls and operating processes that already support the application.

Our senior developers work with the existing product and engineering team to map identity, permissions, service boundaries, workflow states and audit behaviour. From there, we design and build the control layer required for agent access across the application, integrations and data services.

A useful first engagement focuses on one customer workflow. It identifies the authority model that workflow requires, the business capabilities that need to be exposed through the product and the engineering work required to make each action enforceable, traceable and manageable for the customer.