{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreifcnoblzxajgneskbaj5icswnibivrp3r7fu7xdzojtn2nxdlbwbq",
"uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mpadxnovr6e2"
},
"coverImage": {
"$type": "blob",
"ref": {
"$link": "bafkreieke2isps6xpxy2gauqkvco5dh4ng3pdhxofm7m3xooi4yhbyrobq"
},
"mimeType": "image/webp",
"size": 73922
},
"path": "/amising6/why-enterprise-ai-needs-structured-dissent-not-just-more-agents-5cn",
"publishedAt": "2026-06-27T00:53:39.000Z",
"site": "https://dev.to",
"tags": [
"ai",
"agents",
"programming",
"python",
"https://dataengineeringcopilot.com",
"https://github.com/amising6/data-engineering-copilot",
"https://www.linkedin.com/in/amit-singh-57980030"
],
"textContent": "Many AI projects today are presented as multi-agent systems.\n\nOne agent investigates. Another agent analyzes risk. A third agent checks compliance. A fourth agent gives a recommendation.\n\nIt sounds advanced.\n\nBut in a bank, adding more agents does not automatically make a workflow safe.\n\nA bank cannot freeze a customer account, block a payment, file a regulatory report, or label a transaction as fraud simply because an AI system produced a confident answer.\n\nThe real question is not:\n\n> How many AI agents are involved?\n\nThe real question is:\n\n> Can the system show evidence, challenge its own conclusion, apply deterministic rules, and stop for human approval when the decision is high impact?\n\nThat is the difference between an interesting multi-agent demo and an enterprise-ready AI workflow.\n\n## A banking example: suspicious wire transfer\n\nImagine a bank detects a wire transfer for $250,000.\n\nThe payment is unusual because:\n\n * The customer has never sent a transfer of this size.\n * The destination account is in a new country.\n * The transaction happens outside the customer’s normal business hours.\n * The beneficiary was added only a few minutes before the transfer.\n * The customer recently changed their phone number and email address.\n\n\n\nA simple AI chatbot might say:\n\n> “This transaction looks suspicious. Consider blocking it.”\n\nThat is not enough.\n\nA bank needs to know:\n\n * Which transaction patterns triggered the concern?\n * Is the customer actually violating a known risk threshold?\n * Is there a sanctions or AML issue?\n * Could this be a legitimate business payment?\n * What policy applies?\n * Should the payment be blocked, held, or released?\n * Who is allowed to make that decision?\n * Can the bank explain the decision later to auditors, compliance teams, and the customer?\n\n\n\nThis is where structured multi-agent design matters.\n\n## A better design: a banking fraud decision room\n\nInstead of letting one model make a decision, the bank can create a controlled workflow with specialized agents.\n\n\n\n Transaction Alert\n ↓\n Fraud Detection Agent\n ↓\n Customer Behavior Agent\n ↓\n AML / Sanctions Agent\n ↓\n Policy and Risk Agent\n ↓\n Decision Reviewer\n ↓\n Human Compliance Officer\n\n\nEach agent has a limited responsibility.\n\n### 1. Fraud Detection Agent\n\nThis agent analyzes transaction behavior.\n\nIt may identify:\n\n * Unusual payment amount\n * New beneficiary\n * New country\n * Unusual transaction time\n * Sudden profile changes\n * Prior fraud indicators\n\n\n\nIts job is not to freeze the transaction.\n\nIts job is to create a structured fraud signal.\n\n\n\n {\n \"event_type\": \"FRAUD_SIGNAL\",\n \"transaction_id\": \"TXN-784921\",\n \"customer_id\": \"CUST-10048\",\n \"risk_indicators\": [\n \"new_beneficiary\",\n \"amount_12x_customer_average\",\n \"unusual_country\",\n \"recent_contact_change\"\n ],\n \"risk_score\": 82,\n \"confidence\": 0.88\n }\n\n\nThis gives the next stage a reviewable artifact instead of a paragraph generated by an LLM.\n\n### 2. Customer Behavior Agent\n\nA transaction may look suspicious but still be legitimate.\n\nFor example, a corporate customer may be making a valid acquisition payment or paying a new overseas vendor.\n\nThe Customer Behavior Agent looks at:\n\n * Historical payment behavior\n * Customer segment\n * Typical payment ranges\n * Known business relationships\n * Recent support interactions\n * Whether the customer informed the bank about a major payment\n\n\n\nThis agent can produce a counterpoint:\n\n\n\n {\n \"event_type\": \"CUSTOMER_CONTEXT\",\n \"transaction_id\": \"TXN-784921\",\n \"historical_pattern\": \"Outside normal range\",\n \"known_business_event\": \"No supporting event found\",\n \"customer_contacted_bank\": false,\n \"assessment\": \"Transaction behavior remains inconsistent\",\n \"confidence\": 0.76\n }\n\n\nThis is important because the system should not treat every unusual payment as fraud.\n\n## Structured dissent is necessary\n\nNow imagine the fraud agent recommends blocking the payment.\n\nA good enterprise workflow should not simply accept that recommendation.\n\nIt should require another role to challenge it.\n\nFor example:\n\n * The Fraud Agent says: “High fraud risk.”\n * The Customer Context Agent says: “No evidence of a legitimate business event.”\n * The AML Agent says: “Beneficiary has elevated geographic risk.”\n * The Policy Agent says: “The bank’s hold threshold is met.”\n * The Decision Reviewer says: “Human approval required before blocking.”\n\n\n\nThat is structured dissent.\n\nIt is not about making agents argue for entertainment.\n\nIt is about making assumptions visible before the bank takes action.\n\n> In high-stakes workflows, disagreement is not a weakness. Hidden disagreement is the real risk.\n\n## The LLM should not make the final decision alone\n\nLLMs are useful for many parts of the workflow:\n\n * Summarizing transaction history\n * Explaining why a transaction appears unusual\n * Reading customer notes\n * Interpreting investigation findings\n * Drafting a case narrative\n * Generating a compliance-review summary\n\n\n\nBut an LLM should not control deterministic rules.\n\nFor example, these should come from governed systems and rules engines:\n\n * Daily transaction thresholds\n * Sanctions screening results\n * AML policy conditions\n * Regulatory filing timelines\n * Customer account restrictions\n * Approval authority limits\n * Payment-hold policies\n * Risk score calculations\n\n\n\nA safe architecture looks like this:\n\n\n\n AI Layer\n - Investigates\n - Summarizes\n - Explains\n - Recommends\n\n Rules Layer\n - Calculates thresholds\n - Applies risk policies\n - Checks sanctions lists\n - Enforces approval limits\n - Determines required escalation\n\n Human Layer\n - Approves\n - Rejects\n - Overrides\n - Requests further investigation\n\n\nThis distinction matters.\n\nThe AI can explain why a payment looks suspicious.\n\nThe rules engine can determine whether the bank’s fraud-hold threshold has been crossed.\n\nThe compliance officer can decide whether the payment should actually be blocked.\n\n## An evidence panel is more important than a chatbot answer\n\nThe final decision should not be a black-box score.\n\nA compliance officer should see an evidence panel like this:\n\n\n\n Transaction:\n TXN-784921\n\n Customer:\n Corporate customer — existing account for 4 years\n\n Amount:\n $250,000\n\n Risk indicators:\n - New beneficiary\n - New destination country\n - Payment amount is 12x normal average\n - Contact information changed within past 24 hours\n - No matching historical vendor relationship\n\n Policy checks:\n - Enhanced review threshold: Triggered\n - Manual compliance approval: Required\n - Sanctions screening: Clear\n - AML monitoring alert: Triggered\n\n AI assessment:\n High-risk transaction requiring manual review\n\n Human decision:\n Payment placed on temporary hold\n\n Approved by:\n Compliance Officer\n\n Decision timestamp:\n 2026-06-26 14:22 UTC\n\n\nThis is what enterprise AI should produce.\n\nNot just an answer.\n\nA decision record.\n\n## Human approval is part of the architecture\n\nHuman approval should not be added as an afterthought.\n\nIn banking, some actions should be automated.\n\nFor example:\n\nAction | AI / system role | Human role\n---|---|---\nSummarize alert | Automatic | Review if needed\nIdentify unusual transaction patterns | Automatic | Review exceptions\nCreate investigation case | Automatic | Monitor\nPlace temporary low-risk review hold | Rule-based | Review later\nFreeze account | Recommend only | Explicit approval required\nFile SAR or regulatory report | Draft supporting evidence | Compliance approval required\nClose customer account | Never autonomous | Senior human decision\n\nThe system should know when to proceed, when to pause, and when to escalate.\n\nThat is not a limitation.\n\nThat is good enterprise design.\n\n## What this means for data engineering teams\n\nThis same pattern applies directly to data engineering.\n\nA data-engineering copilot should not only generate SQL or YAML from a source-to-target mapping document.\n\nIt should operate as a governed workflow.\n\nFor example:\n\n\n\n STTM / DDL / Source Metadata\n ↓\n Metadata Extraction Agent\n ↓\n Mapping Validation Agent\n ↓\n Transformation Logic Agent\n ↓\n SQL / YAML Generator\n ↓\n Reviewer Agent\n ↓\n Data Engineer Approval\n\n\nThe reviewer should validate things such as:\n\n * Does the source column exist?\n * Is the target data type compatible?\n * Is the join supported by the mapping?\n * Is the transformation rule documented?\n * Is a sign rule missing?\n * Is a derived metric using an unapproved assumption?\n * Are there duplicate or unused YAML objects?\n * Has an engineer approved the generated output?\n\n\n\nThen every generated artifact should include traceability.\n\n\n\n Target Column:\n PROFIT_AMT\n\n Source:\n sales.PROFIT_AMT\n\n Transformation:\n CASE WHEN SALES_TYPE = 'CANCEL'\n THEN PROFIT_AMT* -1\n ELSE PROFIT_AMT\n END\n\n Business Rule:\n Cancellation transactions must store Profit as negative.\n\n Source Reference:\n STTM row 42\n\n Validation:\n - Source column exists\n - Transformation approved\n - Target data type compatible\n - Human review status: Approved\n\n\nThis is how generated code becomes a governed engineering artifact.\n\n## A practical checklist for enterprise AI\n\nBefore calling a multi-agent system enterprise-ready, ask:\n\n 1. Does each agent have a clear responsibility?\n 2. Are handoffs structured instead of free-text only?\n 3. Can one agent challenge another agent’s conclusion?\n 4. Are critical calculations and policy checks deterministic?\n 5. Can every recommendation be traced to source evidence?\n 6. Does the system show assumptions and confidence levels?\n 7. Is there a clear escalation path for uncertainty?\n 8. Can a human approve, reject, or override the decision?\n 9. Can the organization reconstruct the full decision later?\n\n\n\nIf the answer is no, the solution may still be a useful prototype.\n\nBut it is not ready for high-stakes enterprise use.\n\n## Final thought\n\nThe future of enterprise AI is not one intelligent assistant making every decision.\n\nIt is also not a collection of agents talking continuously.\n\nThe future is a governed decision system where AI helps teams investigate faster, compare perspectives, identify risk, and prepare recommendations.\n\nBut evidence remains visible.\n\nRules remain enforceable.\n\nDisagreement remains allowed.\n\nAnd people remain accountable.\n\nThat is how AI becomes useful in banking, finance, data engineering, and other enterprise workflows where trust matters as much as speed.\n\nhttps://dataengineeringcopilot.com\n\nhttps://github.com/amising6/data-engineering-copilot\n\nhttps://www.linkedin.com/in/amit-singh-57980030",
"title": "Why Enterprise AI Needs Structured Dissent, Not Just More Agents"
}