I'll be upfront: I'm not a software engineer. I wasn't trained as one and I don't write production code for a living.
I built a multi-agent AI prototype anyway. Here's an honest account of how, and what it taught me about where AI tooling actually is right now.
The context: I'm building Y-tech Bank, an AI neobank with a business suite called NeuroOffice, eight specialized agents: a Consultant, Designer, Lawyer, Accountant, Marketer, Copywriter, HR Manager and Client Manager. Each is built for a specific domain, and each is designed to draw on the user's real financial context rather than generic advice.
Right now, you open NeuroOffice and pick the agent you need. There's no automatic routing between them, and no memory carried across sessions yet. That's deliberate for this stage, and I'll explain why.
When I started the NeuroOffice prototype, I didn't have a CTO. I had product vision, Claude, and a lot of time.
What I actually used: the Claude API directly, managing conversation state myself by passing history back with each request, and careful system prompts to define each agent's behaviour. I didn't reach for a heavy orchestration framework- partly by choice, partly because doing the hard parts by hand showed me exactly where the real difficulty lives.
What I found: building the individual agents is genuinely accessible now. Getting an AI to behave reliably as a specialized agent, an Accountant that only gives advice grounded in real data, a Lawyer that flags uncertainty instead of inventing legal opinions, is a prompt engineering problem, not a coding problem. It takes careful thinking about what the agent should and shouldn't do, what context it needs, and what failure modes to guard against. But it's doable by a determined non-engineer.
The orchestration layer is the part I chose not to build yet, and hitting the edge of my own ability is exactly why.
An automatic router that reads a request and sends it to the right agent, agents that share memory within a session, context that persists between visits - that's the version I want. It's also the version that needs real engineering: intent classification, multi-agent state, persistence, session management. So for the prototype I did the honest thing a non-engineer can do. I made agent selection manual and each session self-contained.
That's not a limitation I'm hiding. It's the line between what one determined non-engineer can ship and what needs a team. Manual selection let me test each agent in isolation and prove the behaviours actually work. The routing, and the shared, persistent context layer, come with the engineering hire.
So here's the honest picture of AI tooling in 2026:
Single-agent prototype: accessible to a determined non-engineer with good prompting skills.
Multi-agent system with shared, persistent context: needs real engineering. The concepts are clear; the implementation details aren't something you figure out purely from docs.
Production-ready at scale: needs a serious team. Everything I've read from people who've built agent systems in production describes an amount of infrastructure, reliability, monitoring, security, handling failure gracefully at volume, that is simply not a one-person job. I haven't built that layer and I'm not pretending to understand all of it. That's exactly the point: it's the work a real engineering team does, and the reason I'm raising to hire one.
The most important thing I learned about agents: their quality is almost entirely about the quality of their context and constraints, not the underlying model. Vague instructions and unlimited scope produce vague, unreliable output. A precise role definition, clear boundaries, explicit handling of uncertainty, and rich real-world context — in our case, actual financial data, produce something genuinely useful. The prompt is the product. That's more true for agents than for any other kind of AI application.
Why I'm sharing this: there are a lot of founders in my position. Clear product vision, limited engineering bandwidth, building AI products without a technical co-founder yet. The honest message is: you can get further than you think in prototype, and you cannot reach production without real engineering. Use the prototype to validate, to raise, and use the raise to hire the team you actually need.
That's the phase I'm in. The prototype did exactly what it needed to do - it proved the idea works, and it showed me precisely which problems I can't solve alone.
Which is the useful thing a prototype is for.
—
I'm Andrew, founder of Y-tech Bank. I'm looking for a technical co-founder with fintech infrastructure experience, if building AI-native banking from the ground up sounds like your kind of problem, get in touch. ytechbank.com
Top comments (0)