NeuroOffice is a suite of AI agents built into Y-tech Bank’s business layer. Here’s the architecture we’re building and the tradeoffs we’re making- including what works today and what’s still ahead.
The core challenge: several specialized agents, one shared data foundation. Each agent needs different data, has different latency requirements, and produces different output. But from the user’s side it should eventually feel like one coherent system, not several separate chatbots.
Where we are today: the user explicitly picks the agent they need - HR, accountant, lawyer, marketer, and so on. We chose manual selection deliberately for this phase. It keeps things legible while people test individual agents, and it lets us evaluate each one in isolation before we automate routing.
Where we’re heading: an orchestrator that figures out intent and routes automatically, or combines agents for complex requests. “Write a job description for a junior developer” would go to HR. “Create a Q3 financial summary” to the accountant. Multi-step requests would span agents, “plan our Q4 marketing budget and draft the first campaign brief” hits the accountant for budget analysis, then the marketer for the brief. That routing layer is designed but not yet live.
The decision that makes NeuroOffice useful rather than generic is the shared context layer, and this part works today. Every agent has read access to a continuously updated model of the business’s financial state — revenue and trend, expense categories, cash position, patterns. So when an agent gives a recommendation, it’s working from the actual account data, not what someone typed in. (In the current test environment the transactions and balances are simulated, but the agents read and reason over them exactly as they would with live data.)
On latency: different agents have different needs. A CRM agent generating a reply in a live conversation should feel instant. A copywriter drafting an article can take longer. A monthly report can run async in the background. The plan is to use different model sizes and inference strategies per agent rather than one model for everything — matching the model to the task’s latency budget. This is on the roadmap, not shipped.
Honest engineering note: cross-agent consistency is the open problem I’m most focused on for the multi-agent phase. If a marketer and an accountant both reference the same Q3 revenue number in one session, they have to match. The intended approach is a context lock that freezes shared figures for the duration of a multi-agent session, so every agent reads the same snapshot — but since multi-agent sessions aren’t live yet, this is still design-stage. Persistent memory across sessions is ahead too.
Why agents instead of one big model? Each can be tuned on domain-specific data. Failures are isolated — if one agent has issues, the others keep working. High-demand agents can scale independently. And domain-specific evaluation is easier. The tradeoff is orchestration complexity, which for our use case is worth it.
—
Building this at Y-tech Bank. Always up for conversations with engineers working on multi-agent systems. ytechbank.com