Skip to main content

AGENTS OVERVIEW — Q&A


Q: What are the 8 agents in Fincelo? The orchestration engine sits alongside these 8. It is not a governed agent and carries no credit weight — it is the coordination layer that routes events between agents, enforces cooldown locks, and prevents two agents acting on the same customer at the same time.
Q: How does agent governance work — can agents act autonomously? Every agent action has one of 3 governance states: Auto: agent executes immediately, no human approval needed. Approval: action goes to the approval queue, human approves before execution. Disabled: action is switched off for this workspace. Finance teams configure the governance state per action in Settings → Agents. Every auto action is logged with agent name, action type, timestamp, and outcome. Every approval action is logged with who approved, when, and any notes. Fincelo’s principle: agents amplify the CFO’s capacity. They never replace the CFO’s judgement on material decisions. Bad debt write-offs, expansion billing terms, period close Path B and Path C, and churn View A/B selection always require explicit CFO approval, regardless of governance state.
Q: What is the approval queue? A unified inbox for all actions waiting for human approval. Priority levels: P1 (4h expiry), P2 (24h expiry), P3 (no expiry). Expired approvals are escalated to the next person in the chain. Each item shows: what the agent wants to do, why, supporting data, approve/reject buttons. Approving an action executes the real side effect. If execution fails, the failure is surfaced rather than silently swallowed.
Q: What happens if two agents try to act on the same customer simultaneously? The orchestration engine has a conflict prevention system. When Agent A takes an action on Customer X, a cooldown lock is placed. Agent B sees the lock and either waits or routes the action to the queue. No two agents can send a customer communication within the configured cooldown window. Default cooldown: 24 hours per customer per channel. Blackout schedules are also honoured, so agents do not contact customers outside the windows your team defines.
Q: How does the event bus work? All modules and agents communicate via the domain_events table. When a significant event occurs (contract approved, payment received, invoice overdue), an event is written to domain_events. All subscribed modules react to it. Example: PAYMENT_FAILED fires → Collections agent starts dunning, Integration hub sends alert, AI CFO flags the anomaly, Metrics updates failure rate. All 4 reactions happen from one event. No direct module-to-module calls.