An agentic core is the logic of a whole process (originating a loan, collecting a portfolio, serving a customer, closing a month) built on top of the connectors into your systems. It lives in one layer instead of being scattered across separate systems, and it is where the steps, rules, exceptions and human decision points get defined.
What is a core, and why isn't a standalone agent enough?
A standalone agent knows how to do one task. A process is a sequence of tasks with rules, dependencies and exceptions that crosses several systems and several people. The core is where that sequence is written down, tested and governed. Agents work inside the core. If an agent or a model changes, the process stays.
That is why we talk about origination, collections, service and close, and not "a collections bot". Each core brings together three things: the process rules (what happens and in what order), the connectors (which systems it touches, see connectors) and the human decision points (what never happens without a person, see governance).
What does an origination core look like?
It walks an application from arrival to ready for decision:
- Receives the application and documents through whatever channel they come in.
- Checks that the documents are complete and consistent with each other.
- Queries internal systems and the sources your policy allows.
- Assembles the file with what it found and what is missing, and asks the applicant for what's pending.
- Hands the decision-maker an organized file with the evidence in view.
The credit decision is made by the person or the rules engine your institution defines. The core prepares and executes; it doesn't decide outside policy. In regulated sectors, what can be automated and what needs a person is determined by your compliance function and legal advisors, and the core is designed to leave the trail they need.
And a collections core?
Collections is a good example of a process with many exceptions and a lot of bridge work:
- Reads the portfolio in the collections system and segments it by your rules.
- Contacts each customer through the channel they already use, in the tone and during the hours your policy sets, always identifying itself as an agent.
- Records promises to pay, disputes and data changes in the right system.
- Escalates sensitive cases to a person: disputes, complaints, delicate personal situations.
- Reconciles payments received against promises and reports status.
Contact limits (hours, frequency, content) live in the core as verifiable rules, not as a wish in the model's instructions. The audit log records what was said, when and why.
And a customer service core?
A service core connects the conversation to the systems that hold the answer. It understands what the customer wants, looks up the real status in the CRM or whichever system applies, resolves what is within its permissions, and hands a person everything else with the full context. The customer doesn't repeat their story.
What separates it from an FAQ bot is that this core can do things: reschedule, update a record, issue a receipt, open a case, always within the catalog of actions its connector gives it. The channel (voice, web, messaging, email) is how the conversation arrives. The value is in what the core does behind it.
And a month-end close core?
Close is a sequence with dependencies: reconcile, review differences, request explanations, prepare entries, consolidate. A close core:
- Reconciles movements across the accounting system, banks and subledgers.
- Detects differences and classifies them by likely cause.
- Asks each owner for the missing explanation and follows up.
- Prepares proposed entries with their support, for a person to review and approve.
- Leaves a close file with what was done, what is pending and who approved what.
Accounting control isn't delegated: the core cuts the work of assembling and chasing and strengthens the trail, while approvals stay human.
Which core should you start with?
The one that combines three things: a process with volume and definable rules, systems with an available entry point, and a business owner who decides the exceptions. A narrow core that works beats a broad one that half works.
Cores aren't just for our agents. Once built, a core is exposed through open protocols, so your team can reach it from the tools it already uses. To see how one gets built end to end, read how an agentic system is built. For the overview, see the guide.