Agent-first, not dashboard-first
The enterprise fund data platform I used to work on had 200+ screens. Navigation required a training course. Most users touched maybe 6 of them. We're building the opposite.
The default instinct when building a data platform is to create a screen for everything. Fund list screen. Fund detail screen. NAV entry screen. Validation screen. Approval screen. Delivery status screen. Exception screen. Report screen. Admin screen. Another admin screen for the settings that didn't fit on the first admin screen.
Each screen solves a real need. But collectively, they create a product that requires a week of training and a 40-page user guide. Users don't want to navigate 12 screens to process a daily NAV file. They want the NAV file to process itself and tell them if something went wrong.
The agent-first premise
Here's the question we asked: if an AI agent handled 90% of daily fund data operations, what would humans actually need to see?
The answer: exceptions. Humans need to see the things that went wrong, the things that need a decision, and the current state of the system. That's it.
An agent can ingest a file, detect its schema, map fields, validate data, resolve entities, and stage records for delivery. It doesn't need a screen for any of that. It needs a pipeline. Humans only enter the picture when confidence drops below threshold or a business decision is required.
The four screens
We landed on four:
- Pipeline Monitor: What's happening right now? Files in flight, pipes running, delivery status. Think air traffic control, not a filing cabinet. Green means flowing. Amber means attention needed. Red means stopped.
- Exception Queue: What needs human judgment? Low-confidence field mappings. Cross-source discrepancies where two providers disagree on a NAV. Entity resolution candidates below the auto-match threshold. Each item has context, suggested action, and a one-click resolution.
- Fund Explorer: The canonical view of your fund universe. Search, filter, drill into any entity. See all identifiers, all data points, all sources. This is the reference screen — you go here when you need to understand the current state of a specific fund.
- Configuration: Pipeline definitions, validation rules, delivery pipes, user management. The setup screen. You visit this weekly, not daily.
Four screens. A new user can be productive in 15 minutes.
What the agent actually does
The agent isn't a chatbot bolted onto a dashboard. It's the primary execution layer. Here's a typical daily flow:
- File arrives via SFTP. Agent detects provider, identifies schema, applies locked field mapping.
- Agent validates every record against rules: NAV within tolerance, required fields present, identifiers resolvable.
- Clean records flow through to the canonical store. Exceptions get queued with full context.
- Agent checks delivery schedules. Pipes that are ready fire automatically. Gate conditions enforced.
- Agent posts a summary: "Processed 847 records from Provider X. 3 exceptions queued. All delivery pipes fired."
A human glances at the Pipeline Monitor. Green. Checks the Exception Queue. Three items. Reviews them, makes decisions, moves on. Total time: 4 minutes. In the old world, this was a 45-minute process across 8 screens.
The hard part: trust
Agent-first only works if users trust the agent. Trust requires two things: transparency and correctness.
Transparency means every agent action is logged and auditable. You can see exactly why the agent mapped Net Asset Value Per Share to OFST040010. You can see the confidence score. You can see which rule triggered which validation. No black boxes.
The moment an agent makes a decision you can't explain, you've lost the operations team. And you deserve to.
Correctness means the agent doesn't guess. Below-threshold confidence? Exception queue. Ambiguous entity match? Exception queue. New field that wasn't in the locked mapping? Exception queue. The agent is aggressive about admitting uncertainty.
Fewer screens, more leverage
The counterintuitive insight: fewer screens doesn't mean less functionality. It means the functionality lives in the right place. Routine work lives in the agent. Decision-making lives in the exception queue. Reference data lives in the explorer. Configuration lives in config.
Every screen we didn't build is a screen we don't maintain, don't test, don't document, and don't train users on. That's not laziness. That's leverage.
The fund data industry is drowning in dashboards. What it needs is automation with guardrails. Four screens and an agent that knows when to ask for help.