By Farhad Vali, Chief AI Architect, EASICloud
I see agentic customer interaction as the next evolution of digital commerce and customer service: software that can understand a request, work through a service process and help complete it in conversation. Financial conversations make the stakes of that shift especially visible. A useful agent must be able to understand people without being allowed to invent authority, disclose information or commit money. This article describes Eva, the AI Operation Manager EASICloud designed around that distinction: the model interprets, and the application decides.
My ambition is to help build a Canada-first agentic-AI contact centre: one designed for Canadian customers, languages, operating contexts and obligations, and governed for each organization that uses it. That is a direction of work, not a claim about market leadership, national coverage or a completed product for every financial sector.
To me, Canada-first means beginning with Canadian organizations’ workflows, language and accessibility needs, and jurisdiction-specific review rather than retrofitting a generic service. It also means being clear about what has not been built: an ambition describes direction and diligence, not nationwide coverage, compliance or a live contact centre in every sector.
Who I am, and what Eva is
I am the Chief AI Architect at EASICloud, and Eva is the system we designed. EASICloud develops Eva as an AI Operation Manager: the application around a conversational model that manages an operation, controls what may be said or done, records what happened and keeps staff involved in supervision. We designed it using AI for several clients and use cases, shaped by a shared challenge: customer conversations in which a sentence can carry regulatory, financial or evidentiary consequences.
The worked example is the live collections deployment at EASICollect, a collection agency and EASICloud’s client. Collections makes the problem concrete: the customer may not have asked to be contacted, identity must precede account disclosure, money and commitments can come up, and some people need a careful response or a human. Later sections discuss insurance and banking as use cases the architecture was designed to address, not live deployments. Claims about what Eva does today refer only to EASICollect’s collections deployment.
What an AI Operation Manager is, and why AI FinTech needs one
The quick way to put a conversational model on a phone line is a prompt, a voice and a way to contact people: a chatbot with a phone number. Yet a model can misunderstand a sentence, give a different interpretation on a different attempt, or sound confident while being wrong. Those are not problems solved by making a prompt more emphatic. They are reasons not to put a probabilistic component in charge of decisions with real-world consequences.
An AI Operation Manager is the alternative: the application that owns the operation and treats the conversational model as one replaceable component. It determines whether a contact is appropriate, what information may be shared, whether an action is authorized, how effects are recorded and what staff can review or change. The model listens, transcribes and suggests what a customer might mean; the application checks that suggestion against the current workflow, evidence and approved policy before it decides what happens next.
AI FinTech needs this layer because a financial conversation can involve regulated contact, private information, money, commitments, vulnerable people and records that may later need to be explained. A probability-based model can help interpret language, but application policy must make the operational decisions in a consistent and reviewable way.
In plain language, probabilistic means the model weighs patterns and produces the interpretation it considers most likely; the same words can sometimes produce a different interpretation, and the interpretation can be mistaken. Deterministic policy means that, given the same relevant facts and the same policy version, the application applies the same stated rule. For example, the model may suggest that a caller agreed, but the application checks whether the relevant terms were presented and whether the customer’s response meets the configured requirement before saving anything. The model can help with understanding; it cannot turn its own guess into permission.
This distinction is useful well beyond payment conversations. A model might classify a request as a complaint, summarize a caller’s explanation or suggest that a person is asking to update their details. Those are helpful signals, not final records or grants of authority. The application needs to establish which facts it can rely on, which rules govern the request and whether a person must review it. It should preserve the customer’s words and the basis for its outcome so staff can investigate a disagreement rather than treating the model’s interpretation as a transcript of what objectively happened.
I see agentic interaction as more than a voice interface that retrieves answers. In a customer-service setting, an agent may need to coordinate several parts of an operation: understand the request, consult an authorized source, explain available options, and carry out an approved next step. Each added capability introduces questions of authority, privacy, reversibility and responsibility. A model’s ability to use a tool does not mean that a customer has authorized its use, or that the organization has approved that use for every situation. The application must connect the customer experience to the organization’s decisions and its means of review.
Agent governance is part of this design, not a final checklist. Each deployment needs an accountable owner, a description of what the agent may do, limits on access and actions, a staff escalation path, and a way to review outcomes and complaints. The client must decide who approves policy and wording, who can change them, who monitors performance and who is responsible when something goes wrong. In this article, “approved” and “reviewed” describe decisions made by or for the organization accountable for a deployment; they do not mean approval by a regulator or certification by an independent body. The system’s logs and controls can support those responsibilities; they cannot assign them on behalf of the organization.
A deployment-specific review should consider applicable law and guidance, client policy, jurisdiction, the customer population, languages, accessibility, information the agent can access, retention and disclosure practices, security, staff training and service continuity. Review should cover the intended uses and foreseeable failures, including an incorrect interpretation, incomplete evidence, unavailable services and a customer who needs a person. A change to a workflow, model or connected service can alter the risk, so governance continues after the initial launch.
Independent assurance or certification may be relevant, but it depends on the deployment, the claims being made and the standard under consideration. The organization should identify what is being assessed, who is qualified to assess it and what evidence that assessment requires. Describing safeguards in this article does not establish their effectiveness for every use, and this article does not claim that Eva or any Eva deployment has independent assurance, certification or legal approval.
Governance also includes learning from the service after it begins operating. Teams need a way to identify recurring pauses, complaints, misunderstood requests and mismatches between the expected and reported outcomes. Reviewing such patterns can expose a confusing explanation, an incomplete escalation path or an assumption that no longer holds. Changes should be assessed before they reach customers, and improvements should be checked against both the original concern and new cases they might introduce. This feedback should include staff who handle exceptions and, where appropriate, customer experience. It is not a substitute for a formal compliance review or independent assessment; it helps the accountable organization decide when those reviews are needed and whether the operation remains within the scope it approved.
Architectural principles
Each of these exists because of a specific way the alternative fails.
- The model interprets; the application decides. A model’s reading of a conversation is a proposal, not proof of identity, agreement or authority to act.
- Keep integrations at the edges. External services carry information and carry out authorized actions; the application remains responsible for the decision and checks what comes back.
- Give each interaction one clear owner. A single application process coordinates the conversation so concurrent events do not create conflicting decisions or duplicate effects.
- Keep policy explicit, consistent and reviewable. The application applies the deployment’s configured rules; prompts may explain the conversation but are not a substitute for those rules.
- Protect private information. Verify that the person may receive the information before disclosing account-specific details, using evidence appropriate to the action.
- Treat consent as evidence. A commitment is recorded only when the required terms and customer response are present, not because an answer merely sounds positive.
- Pause when safety, a dispute or uncertainty requires it. A request for help, a stop, missing evidence or an unresolved question must lead to the configured safe outcome, not a guessed next step.
- Make consequential effects traceable. Record what action was intended, whether it was attempted and what confirmation was received; investigate uncertainty rather than blindly repeating an action.
- Keep a conversation anchored to the conditions it began with. Changes to scripts, settings or customer facts should not silently alter the meaning of an interaction already underway.
- Use reviewed wording and preserve the record. Important language should be approved for the deployment, while the history should distinguish what the system attempted from what actually happened.
- Separate shared safeguards from domain rules. Common controls can be reused, while each operation brings its own workflow, evidence, limits and approved actions.
These principles are intended to make the operation explainable to more than its designers. A customer should receive a clear answer and a meaningful path forward; staff should be able to understand why the system paused or acted; and a client should be able to review whether the configured operation matches its own responsibilities. None of those outcomes follows automatically from a model’s fluency. They depend on how the complete service is designed, reviewed and run.
Why a financial conversation is a hard place for an AI
A financial conversation is not simply a customer-service chat with a phone attached: the organization may later need to explain why it contacted someone, what information it shared, what the person agreed to and what action followed.
Contact itself may be subject to rules that vary by jurisdiction, channel, client and purpose. A collections contact, an insurance reminder and a bank’s service call do not necessarily share the same requirements. The system needs to apply the rules approved for the specific deployment rather than treating one configuration as universal.
Identity comes before disclosure. An insurer should not read a claim’s status to whoever answers the policyholder’s phone, any more than the agency should state a balance to an unverified caller. Caller ID is not identity, and neither is a name alone.
Money and commitments need appropriate authorization and evidence. A payment arrangement, a reinstatement request or a change to an account may require the customer to hear and accept specific terms. A vague or interrupted response should not be turned into a commitment.
Some customers may be distressed, vulnerable or facing an emergency. The response needs to be established with the client, reviewed for the deployment and designed to stop the ordinary business process when appropriate. A bereavement conversation, for example, calls for care and approved language rather than an improvised sales or service script.
The organization also needs a reliable account of what happened. A duplicate payment request, private information disclosed to the wrong person, an unsupported coverage opinion or a poorly designed fraud question can have consequences that are not undone by a later correction. This is why Eva’s application, rather than its conversational model, controls consequential actions.
The same exchange can be interpreted differently by the customer, the employee and the automated system. A courteous “I will think about it” should not become an accepted payment plan simply because the model associates the phrase with agreement. A caller’s account of an event should not turn into a verified fact without an appropriate source. A question about a claim may request a status update, but that does not mean every note in the client’s file is suitable to disclose. Good system design keeps these meanings and permissions separate.
These concerns also affect service quality, not only risk management. A system that pauses for no stated reason frustrates customers and staff. One that confidently gives an unsupported answer can undermine trust even when the underlying error is later corrected. The application should explain what information is missing or why the request needs a person, while the client determines the specific language and escalation route. The best response is not always an automated completion; sometimes it is a clear boundary and a useful hand-off.
The shape of the system
Figure 1. Eva coordinates the interaction across people and supporting services; the model informs the conversation, while the application governs actions and records.
Figure 1 uses the collections deployment as its reference. Other customer-service domains may use different records, communication channels and controls.
The customer speaks with Eva through a communication channel. That channel carries the conversation, but does not decide what the customer is eligible to hear or what action the organization should take.
The conversational model helps understand what the customer said and can suggest a likely meaning. The application controls what context is shared with the model and checks any interpretation before using it.
The client’s records remain the source of account information. Communication services may carry an approved message or connect a person with staff, and evidence storage helps preserve the interaction. Staff review activity through the organization’s oversight tools. Which services and actions are available depends on the deployment.
The picture is deliberately about roles rather than a catalogue of products. A financial organization may operate its records, communication channels and staff tools in different combinations. The architecture should make it possible to identify which part owns a fact, which part interprets a customer’s words, and which part is authorized to take an action. Keeping those roles visible helps a client assess its own dependencies and avoid assuming that the conversational model is the source of truth.
Where decisions live
Figure 2. The model can help interpret a conversation; the application applies policy before deciding or acting.
The important boundary is not a particular software layout but a division of responsibility: interpretation can be probabilistic; consequential policy decisions must be governed by the application.
Connections to external services carry information in and out. They do not decide what a customer may be told or whether an action is allowed.
The application coordinates the interaction, checks incoming information, applies policy and authorizes any action.
Policy and workflow define the permitted stages, required evidence, safeguards and approved actions for the deployment. In the current product those domain rules are for collections.
The record and staff oversight preserve enough context for review, follow-up and accountability.
Prompts and interaction instructions may shape how the model communicates, but they are not policy controls. The model cannot make a proposed interpretation authoritative by stating it confidently. A new action should be assessed by asking what evidence authorizes it, which policy applies, how a person can review it and what happens if the result is uncertain.
This separation also makes changes easier to reason about. A client may revise the wording of an explanation without changing the rule that determines whether information can be shared. A model may improve at understanding a language or phrasing without gaining new permission to update an account. Keeping presentation separate from authorization gives reviewers a more focused question: what changed, who approved it, what evidence supports the decision and what tests or review are needed before customers encounter it?
The worked example: a collections call at EASICollect
This section is the collections deployment as it runs for EASICollect today; here “debtor” and “agency” are the right words, and the system of record is the agency’s own.
Life of a call
Figure 3. A customer interaction moves from preparation to a policy-governed response, with a safe pause or staff support when it cannot proceed.
The live collections workflow begins by checking that the interaction can proceed safely and that the required services are available. Eva then engages the customer, the application tracks the conversation against its workflow, and the relevant policy determines which information or actions are permitted.
Collections is a useful example because a single conversation can involve customer identity, an account record, regulated contact, a request for help, a financial commitment and a message sent after the call. The design treats these as distinct responsibilities rather than letting a general-purpose conversational model decide that they have all been satisfied. The application provides the structure; the person remains part of the interaction, and the organization’s staff remain responsible for matters outside the approved scope.
For outbound contact, staff authorization and the applicable eligibility checks govern whether an interaction may start. The interaction uses a consistent view of its relevant facts and policy. If the outcome of an external action is uncertain, the system preserves that uncertainty for review rather than assuming success or repeating the action.
Opening and identity. Eva introduces the interaction without exposing private account information. Before account-specific details are shared, the application requires identity evidence that meets the deployment’s approved standard. A model’s interpretation is not itself verification. If the evidence is insufficient or the person is not the intended recipient, the workflow does not disclose those details and follows an approved alternative or ends the interaction.
Safety and customer choice. Safety concerns, disputes, requests for a person, incorrect-recipient concerns and requests to stop can override the ordinary workflow. The application routes these according to the safeguards and escalation options approved for the deployment.
Money and commitments. If a caller asks about payment, the application uses the current approved options and the terms configured for that client. It requires an adequate indication of agreement before recording a commitment, and confirms an action only after the system can establish that it was completed. The model’s interpretation of an affirmative-sounding phrase cannot replace those checks.
Actions and follow-up. Any permitted message or other action is handled separately from the conversation that requested it, with the result recorded. Eva uses approved closing language, and the interaction record is available for subsequent staff review. A delay in background processing should not leave a customer stuck in an unfinished conversation.
Safety and refusal come before everything
Responses to safety concerns are established with the client and reviewed for the deployment. They should be clear about what the service can and cannot do, and should not suggest that help has been contacted unless it has. A conversational model may help identify language that needs attention, but the application must route the concern according to an agreed safety process; this is not a substitute for clinical assessment.
Disputes pause the ordinary collections conversation and follow the client’s review process. Uncertainty is not consent: when the application cannot establish what the caller means or whether a requirement is met, it asks for clarification where appropriate or pauses for staff review rather than inferring permission.
Readiness before any real contact
Figure 4. Contact readiness depends on current evidence, deployment policy and client authorization; unknowns do not silently become permission.
Before a real contact may proceed, the application checks the evidence and client-approved policy relevant to that contact. Depending on the deployment, those checks can include jurisdiction, authority to contact, the status of notices and previous interactions, open disputes or other holds, the customer’s local contact preferences, channel readiness and approved wording. The applicable requirements vary and must be reviewed for the organization and the circumstances; this article is not a statement of law or a complete compliance checklist.
Where the system cannot establish that a required condition is met, it blocks or routes the contact for review. Staff can see why a decision was made. These safeguards describe the design of the EASICollect collections deployment, not a guarantee that every legal obligation is satisfied in every case.
State, time and truth
The interaction is tied to the relevant customer facts, approved wording and policy available when it begins. This helps staff understand the context of a past decision and prevents an in-progress conversation from silently changing when settings are updated. The application also coordinates competing events so a late or repeated signal does not automatically become a second action.
Consequential actions are recorded as intentions, attempts and reported outcomes. If an action’s result cannot be established, the record keeps that uncertainty visible for follow-up rather than claiming the action succeeded or repeating it automatically. An interaction history should make clear which information came from a person, which came from the model and what the application decided.
A communication service reporting that a connection ended does not prove that a business request was completed. Likewise, a customer agreeing to terms, a message being sent and a payment being received are separate events and should not be conflated.
Approved wording, in the caller’s language
Important wording is reviewed for the client’s deployment and selected by the application according to the workflow. Customer-specific facts are supplied by the application rather than invented by the model. Where exact language matters, it should be delivered as approved; where a conversational response is appropriate, it still has to stay within the facts and actions the application allows. Language coverage and translations require their own review and should not be assumed from the presence of a script library.
If a turn is unclear, the system can ask the customer to clarify or direct the matter to staff. It should preserve what has already been established and avoid treating an incomplete exchange as consent.
The staff side
Staff oversight is part of the operation. Staff can review interaction activity and relevant evidence, while automated guidance remains a suggestion rather than proof of what was said or authority to act. The interface should make stale or uncertain information visible.
Staff review customer records and can follow up on matters that automation cannot resolve. Access is limited by role and client responsibility. A lookup for staff reference is separate from an operational authorization: seeing an account does not by itself permit an automated contact or action.
Automation that prepares possible contacts can be reviewed separately from live execution. A simulation can help show what a process would do under its current assumptions, but it is not approval to contact anyone or evidence that a deployment is ready.
The review record can bring together the interaction, relevant decisions, available evidence and outcomes. Access and retention must follow the client’s approved policy and applicable requirements; they are not universal settings that this article can prescribe.
Testing without touching the real world
The Test Lab exercises the collections workflow with synthetic customer records and isolated effects so teams can evaluate changes without treating a simulated interaction as a real customer contact. Testing should cover both ordinary outcomes and pauses, errors and hand-offs. Before a deployment is used with real customers, the client still needs its own operational, legal, security and compliance review.
Testing can ask whether expected policy outcomes remain consistent when a caller uses different words, changes topics, supplies incomplete information or corrects an earlier statement. It can also check whether staff can understand the reason for a pause and whether the interaction record distinguishes an attempted action from a confirmed result. These are examples of evaluation questions, not a claim that any finite test set proves safety or compliance. Results need interpretation by the people accountable for the deployment.
One core, many operations
Figure 5. Collections is the live worked example; insurance and banking remain design use cases. Each domain would need its own policy and review around shared architectural safeguards.
The shared architecture separates the model’s interpretation from the application’s decisions, keeps consequential actions under application control, and supports evidence, review and staff involvement. These are design principles that can inform different operations; they do not make the rules for those operations interchangeable.
A domain-specific design supplies its own customer journeys, evidence, approved wording, contact conditions, safeguards, escalation routes and permitted actions. Those details must be developed and reviewed for the organization and jurisdiction that would use them.
In the live EASICollect deployment, the domain rules and workflow are for collections. Eva does not currently have a finished mechanism that loads insurance or banking configurations at runtime. Each is a future design use case that would require additional development and a separate deployment-specific review, not a switch that turns on a ready-made service.
A shared architecture is valuable only if it leaves room for real differences. Customer expectations, records, authorization, professional responsibilities and the cost of a mistake can vary substantially between a collection agency, an insurer and a bank. Reusing the decision boundary or evidence concepts does not mean reusing a call script or copying legal rules. A new operation would need to begin with the client’s service design and a clear account of what must remain under human judgment.
The same manager in an insurance call centre
An insurance operation could involve a policyholder contacting an insurer or broker about a claim, a renewal, a payment or an appointment. The architecture was designed with such use cases in mind, but Eva is not deployed for any insurer or broker; the scenarios in this section are design illustrations, not descriptions of a service in operation.
For a claim enquiry, an application would need to verify the person and limit what information it shares to what the client has approved. For a first report of a loss, a conversational model might help collect the customer’s account, but the application would need to validate what is recorded and avoid presenting an automated coverage opinion as the insurer’s determination. Questions requiring a licensed or otherwise qualified professional would need an appropriate hand-off.
Renewal and payment reminders would require rules specific to the insurer, jurisdiction and channel; collections policy cannot simply be carried over. A payment, policy change, appointment or document request would also need a clear authorization path and an accurate record of whether the action was completed.
That design would need to account for complaints, disputes, suspected fraud, bereavement and declared disasters, using wording and escalation routes reviewed by the organization. Coverage questions and disputed decisions belong with an appropriately qualified person. A system should say that a hand-off was requested, not imply a human has taken over until that has been confirmed.
The insurer or broker would also need to establish which records Eva could consult, what a customer can reasonably expect during each type of enquiry, and how to handle situations where a policyholder is distressed or an event affects many customers at once. A technically correct answer can still be inappropriate if it exposes information beyond the customer’s need or presents an unreviewed interpretation as an official decision. Those choices belong to the organization and its qualified reviewers.
The same manager in a bank’s call centre
Banking is another design use case, not a deployment; Eva is not in use at any bank. Potential customer interactions include account service, fraud concerns, payment questions, complaints and appointment requests.
For a potential fraud enquiry, the bank would need to define what can safely be discussed and how the customer can be authenticated. Verification should not invite a customer to disclose secret credentials. Any suspected unauthorized activity or transaction dispute would need to follow the bank’s own fraud and dispute processes rather than be settled by a conversational model.
Payment questions or service requests would require bank-approved contact rules and identity checks appropriate to each action. A request that changes sensitive account information may need stronger verification or a human review than a general enquiry. These requirements would need to be designed and assessed with the bank; they are not inherited from the collections deployment.
Complaints, hardship and vulnerability concerns call for an agreed way to pause, record the issue and involve staff. The bank would need to set the disclosure, evidence, privacy, recording and retention requirements for its own deployment. No single contact flow should be assumed to satisfy another institution’s obligations.
The design review would also need to distinguish between a useful service action and a sensitive change that requires a different assurance level, a separate approval or a person. The bank would determine those boundaries in light of its services and responsibilities. The agent should not improvise them from general knowledge, nor should an example in an architecture article be mistaken for a bank’s approved operating procedure.
What changes per domain, and what never changes
What changes. The customer, organization, records and purpose of each interaction. The workflow, applicable rules, required evidence, approved wording, identity standard, escalation routes and actions the client chooses to automate. Each deployment needs review against its actual jurisdiction, business responsibilities and customer expectations.
What never changes. A model’s interpretation is not authority. The application applies explicit policy, checks evidence before consequential actions, stops when required information is missing, preserves the distinction between an attempted action and a completed one, and supports staff oversight. Testing and simulation can inform a review, but do not by themselves establish approval, legal compliance or independent assurance.
Lessons I would repeat
Keep responsibility clear. The systems that carry a conversation should not also decide what the organization is allowed to do.
Make uncertainty visible. When the system cannot establish whether a step succeeded or a requirement was met, it should preserve that uncertainty for people to resolve.
Consent is evidence, not a tone of voice. A response that sounds positive is not enough if the applicable requirements for a commitment have not been met.
Evidence over inference. Missing facts should prompt review or stop an action rather than be filled in with an assumption.
Simulation is not approval. A process that works in a test has not yet passed deployment-specific legal, operational or independent review.
Keep customer interactions responsive. Some work, such as looking up a customer record, depends on a separate system and takes time to return. Measure the whole interaction, make delays and failures understandable, and avoid making a customer wait without explanation.
Design for the actual operation. Shared safeguards can provide a starting point, but a new domain brings its own rules, customer needs and failure modes. An unknown condition should never be treated as permission simply because the conversation seems routine.
Closing
The engineering in Eva is mostly about making its limits enforceable rather than hopeful. Agentic customer interaction may be the next stage of digital commerce and service, but in financial operations it must be earned through clear governance, careful review and accountability for outcomes. If you are building AI Operation Management for a financial operation, I would like to hear how you draw the line between interpreting and deciding.
Farhad Vali is Chief AI Architect at EASICloud, where Eva is designed and developed. The views in this article are the author’s own. Comments and disagreement are welcome.
