Match the technology to each step
AI agents work multi-step cases; AI models read and draft. Where an error is costly, calculations, permissions, and postings run on deterministic code.
Every action has an owner and leaves a record.
The architecture follows a service through five layers, from the request to the accepted output.
From the request to the record
The layers behind a service.
- 01
Channels and intake
Receive requests through the agreed customer, partner, and system channels.
- 02
Service coordination
Track case progress, owners, and the permitted next actions.
- 03
Execution and AI agents
Use AI agents, AI models, and approved rules to do the work.
- 04
Systems of record
Update or reconcile your systems through authorized interfaces.
- 05
Oversight and evidence
Keep the records that measure delivery, show decisions, and support recovery.
In the open modules
Seven layers, from channels to provider systems.
Open a layer to see what it contributes and where its work ends.
01ExperiencesJourney APIs for customers and operators.
Web and mobile experiences, partner portals, and operations tools call journey APIs, each with its own entry point.
- exp-onboarding
- exp-accounts
- exp-distributor
02Business domainsCommands, queries and coordination across capabilities.
Domain services coordinate the core services; an account-opening saga links the agreement, holder, account, and first transaction.
- domain-banking-accounts
- domain-customer-people
- domain-product-catalog
03Core records and servicesFocused APIs, data models and persistence.
Each core module owns one record, such as a party, a contract, or an account, behind REST/OpenAPI contracts.
- core-common-customer-mgmt
- core-common-contract-mgmt
- core-banking-accounts
04Integration boundariesProvider systems, connected in one place.
Provider interfaces keep payment rails, documents, signing, and insurer systems behind explicit contracts, with error handling and reconciliation.
- library-rails
- library-psps
- fireflyframework-ecm
Design principles
How the work stays under control.
Design the exception path alongside the normal path
Delays, ambiguous evidence, and partial failures are part of the process, so the service defines how to pause, resume, and reconcile.
Keep institutional authority visible
A proposed action is not an authorized one, and delegated limits apply to automated and human work alike.
Inside a service
Keep business logic independent of its connections.
A port says what the use case needs and an adapter supplies it, so a new database or provider stays inside its adapter.
- 2Repository port
Persist business records
Selected relational database - 3Event publisher
Notify other services
Selected message broker - 4External-service port
Request a provider action
Provider API adapter
Architecture decisions
Design for the whole operation.
API contracts
Define inputs, outputs, authorization, and versions, with idempotent retries where the service supports them.
Data and events
Choose which service owns each record, and use event sourcing where it earns its place.
Process state
Keep long-running work in a persisted runtime; in-memory timers die with a restart.
Identity and access
Separate who a user or service is from what it may do, with OAuth2/JWT and policy contracts.
Operational evidence
Trace every request, and agree how to reconcile when an external system acted but its response was lost.
AI within limits
Model output is typed information; permissions and your approval decide what proceeds.
Open engineering foundations
The frameworks behind the design.
Firefly Framework supplies the service, data, event, security, process, and AI patterns the platform uses.
Your first operation
Bring us one operation.
Tell us the process, the volume, and what “done” looks like. We will come back with a scope, a deployment plan, and a proposal.