Chief Operating Officer AI

Invoked when: annual operating plan cycle, new product launch requiring ops design, or a systemic ops failure requiring structural review

• –Reads the current state of lending operations — throughput by stage, SLA performance, rework rates, exception handling volumes, and team capacity utilisation — alongside the business volume plan for the planning period, and produces a gap analysis between what the current ops structure can deliver and what the plan requires.
• –Designs the target operating model for the planning period: which stages in the loan journey should be handled in-house vs outsourced, where automation can replace manual steps without introducing credit or compliance risk, and how the operations team should be structured to handle peak volumes without over-hiring for average volumes.
• –Maps every proposed structural change against the compliance and credit policy constraints that operations must work within — a process change that speeds up disbursement by skipping a document check is not an efficiency gain, it is a compliance risk. The strategy recommendations are bounded by what the CRO AI and CCO AI confirm is acceptable.
• –Does not determine budget allocations, headcount numbers, or technology investment decisions. It identifies the structural requirements; the human COO makes the resource allocation decisions based on those requirements alongside the financial plan.

Invoked when: monthly capacity review due, disbursement volume forecast revised, or a specific team is showing queue build-up

• –Reads the disbursement volume forecast by product and channel for the next 4–12 weeks, the current team capacity by ops stage — headcount, productivity benchmarks, leave and attrition assumptions — and models whether each stage of the operations pipeline has sufficient capacity to process the forecast volume within SLA.
• –Identifies specific capacity pinch points: a stage where the current team can handle 80% of the forecast volume within SLA but will breach at 100%, giving the human ops manager a 4–6 week lead time to hire, train, or reallocate before the breach happens rather than discovering it when queues are already overflowing.
• –Models the impact of attrition and leave on capacity — a team of 10 processors with 3 on leave and 1 recently resigned has the effective capacity of 6, not 10. The plan must reflect this adjusted capacity, not the nominal headcount figure that organisational charts show.
• –Cannot factor in individual employee performance variation, informal mentoring loads on senior staff, or the ramp-up time a new hire needs before reaching full productivity — these require human ops manager judgement to overlay on top of the structural capacity model.

Invoked when: daily ops data available for health check, or weekly SLA review with business and product teams due

• –Reads the stage-wise TAT data for every loan in the active pipeline — time in each ops stage against the contracted or target SLA — and produces a real-time SLA compliance report that identifies which stages are within SLA, which are breaching, and which are at risk of breaching within 24 hours if current throughput rates continue.
• –Distinguishes between SLA breaches caused by ops capacity issues (queue has built up because throughput is insufficient), quality issues (rework loops are adding TAT), system issues (a CBS or API outage added processing time), and upstream issues (applications arriving incomplete, requiring re-documentation that adds time the ops team cannot control).
• –Tracks SLA performance trends over time — a stage that is within SLA today but has been creeping upward over four weeks is heading for a breach even if it has not crossed the line yet. The trend alert is more useful than the breach alert because it gives time to intervene.
• –Does not override SLA commitments or approve SLA exceptions for specific customers. SLA breach communications to customers or business partners, and decisions to grant TAT extensions, are made by the human ops head.

Invoked when: weekly vendor performance data available, a vendor SLA breach is flagged, or a vendor contract is due for renewal

• –Reads vendor-wise performance data for every outsourced ops function — document processing, VKYC, bureau pulls, disbursement processing, legal document verification — and scores each vendor against their contracted SLA across accuracy, TAT, uptime, and escalation response time. Identifies vendors that are consistently meeting SLA, those in chronic breach, and those showing a deteriorating trend.
• –For SLA breaches: reads the breach log and the vendor's contractual SLA remedy provisions — penalty clauses, cure period timelines, escalation obligations — and produces a breach management recommendation: is this within the contractual cure period (monitor and hold), has the cure period expired (trigger penalty clause), or is the pattern systemic (recommend contract review)?
• –At contract renewal: reads the full performance history, breach and penalty record, current market pricing benchmarks (where provided), and the strategic dependency assessment — vendors that have become single points of failure in a critical process need to be treated differently in renewal negotiations than easily substitutable commodity services.
• –Cannot negotiate with vendors, issue contract notices, or make commitments on commercial terms. Vendor relationship management and commercial negotiations are conducted by the human COO and procurement team using the agent's analysis as the evidentiary base.

Invoked when: a stage is consistently underperforming on TAT or quality, a new automation tool is being evaluated, or an annual process review cycle is due

• –Reads the process documentation for the stage under review alongside the actual performance data — TAT, rework rate, exception volume, error type distribution — and maps where the designed process and the actual process diverge: steps that are being skipped, informal workarounds that have become standard practice, and quality checks that are creating rework loops that the process design does not account for.
• –Identifies the root cause of performance gaps using the data available: a high rework rate caused by incomplete applications from the origination channel requires a fix upstream (better document checklist at the point of application), not more rework capacity downstream. The agent diagnoses the cause before recommending the intervention.
• –Evaluates automation opportunities — where in the process is manual effort being applied to tasks that a rule-based or ML system could handle with equivalent or better accuracy? Maps the potential TAT improvement, cost saving, and quality impact for each automation opportunity, alongside the implementation complexity and the compliance review required before automated processing is deployed.
• –Does not redesign processes autonomously or recommend changes that would affect credit policy compliance without routing the proposed change through the CRO AI and CCO AI for sign-off. A process change that touches a compliance checkpoint requires a compliance review before it can be implemented, regardless of the efficiency gain it offers.