DEV Community: Andrew Yakush

How I built a agent AI system without a technical co-founder

Andrew Yakush — Mon, 20 Jul 2026 06:32:05 +0000

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

KYC/AML in 2025: building identity verification from day one

Andrew Yakush — Fri, 17 Jul 2026 07:20:00 +0000

If you’re building anything in financial services, KYC and AML aren’t features you add later. They’re constraints that shape your whole architecture. Here’s how I think about them building Y-tech Bank.

KYC (Know Your Customer) is verifying that users are who they claim to be. In EU/UK banking that means identity document verification, a biometric liveness check, address verification, sanctions screening against EU/UK/UN lists, and PEP (politically exposed persons) screening.

AML (Anti-Money Laundering) is the ongoing monitoring for suspicious activity: transaction monitoring rules, customer risk scoring that updates continuously, suspicious activity reports filed with financial intelligence units, and enhanced due diligence for higher-risk customers.

The regulatory ground is moving under you, which matters for how you build.

Most AML explainers still reference the old directive-based framework. That’s out of date. The EU adopted a new AML package in 2024: the AMLR (Regulation 2024/1624), AMLD6 (Directive 2024/1640), and AMLA — a new central supervisor in Frankfurt, operational since July 2025.

The structural change is the same one happening across EU financial regulation right now: the substantive rules moved from a directive (transposed 27 different ways) into a regulation that applies directly and identically in every member state. Full application is 10 July 2027, with AMLA publishing 23 technical standards through 2026.

Why this is an architecture problem, not a legal one: if you’re building now, you’re building for a rulebook that becomes uniform across the EU in 2027. Designing around today’s national variations is designing for a world that’s ending. And one specific note for anyone doing what I’m doing: AMLA’s supervisory expectations are expected to include scrutiny of automated compliance systems. If your transaction monitoring is AI-driven, it has to be auditable and explainable. Not eventually. By design.

The architecture decision that matters most: the temptation in an MVP is to stub out KYC/AML with a simple integration and “do it properly later.” That creates serious technical debt, because these requirements touch your data model at a fundamental level. Customer risk scores need to be accessible across the whole app. Transaction monitoring needs to run in real time, not in nightly batches. Your audit trail — every compliance decision, every report, every screening result — has to be immutable and queryable. Skip this at the start and you’re refactoring everything later, with compliance gaps that are hard to close.

How I’m building it: onboarding runs identity verification through a specialist provider, then an initial risk score, which writes to a persistent customer risk profile with versioned, immutable history. A continuous monitoring layer handles transaction rules, behavioural anomaly detection, and daily sanctions/PEP re-screening. Flagged activity goes to automated holds or a human review queue, and everything writes to an append-only audit log.

Key decisions:

Immutable audit trail from day one — regulators will ask for it, and retrofitting one is worse than building it.

Risk score as a first-class data entity with its own version history, not a derived calculation you recompute on demand.

Third-party verification, own decisioning — a specialist handles document and liveness checks, but the risk logic stays in-house. That logic is the thing you’ll be asked to explain.

Real-time transaction monitoring rather than batch. Re-screening can be batched. Monitoring can’t — and with SEPA Instant mandatory, the whole compliance decision now has to clear inside a 10-second window. Batch architecture is simply not compatible with instant settlement.

Evaluating KYC providers for EU/UK — Sumsub, Onfido, Jumio, IDnow are the main ones — look at country and document coverage (27+ for EU), false-positive rate (too many false declines means lost customers), API and webhook quality, pricing model against your expected volume, and their own certifications (ISO 27001, SOC 2, experience with FCA/BaFin clients).

Honest time estimate: a compliance-ready KYC/AML system — not a stub, something you’d show a regulator — takes longer than most founders plan. Budget 3–4 months for a solid initial build, plus ongoing maintenance as rules change and your monitoring evolves with real data.

And the honest caveat: I’m pre-licence. This is the architecture, and the reasoning behind it, from someone designing it now rather than someone who’s already been examined on it. If you’ve been through the other side of that, I’d genuinely like to hear where this thinking breaks.

It’s not glamorous. It’s what separates products that can become licensed banks from interesting prototypes.

—

Y-tech Bank — pre-seed, EU & UK. ytechbank.com

How we designed the NeuroOffice AI agent architecture

Andrew Yakush — Mon, 13 Jul 2026 08:32:21 +0000

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

What Building a Fintech MVP Taught Me That SaaS Advice Never Mentions

Andrew Yakush — Fri, 10 Jul 2026 06:01:15 +0000

Building a fintech MVP is different from building a regular SaaS MVP. The compliance layer alone adds complexity that most startup advice skips entirely. Here’s what I learned building Y-tech’s MVP solo, and what I’d do differently.

The stack: React Native (cross-platform, mobile-first), AWS (scalability, EU data residency), PostgreSQL for transactional data, and an event-driven architecture from day one. That last one was the right call — it made the audit trail almost fall out of the design for free.

What I’d change: I spent too long on infrastructure choices that don’t matter yet. Blockchain anchoring for transaction integrity is in the plan for the production bank — it’s the right answer when you’re handling real money at scale. But I caught myself designing for that world before I’d proven the flows in this one. The MVP didn’t need it, and thinking about it cost me time I should have spent on onboarding.

Compliance surprised me most. I knew fintech was regulated. I underestimated how early the compliance thinking has to start — not at licensing time, but at architecture time.

KYC/AML shapes your onboarding flow. GDPR shapes your data architecture. PSD2 shapes your API design. Skip these at the start and you’re refactoring everything later.

The upside: building compliance-first made the architecture cleaner. Immutable audit logs, consent management, data minimisation — these are good engineering habits regardless of regulation.

I almost got the ordering wrong. Early on I wanted to build NeuroOffice (our AI business suite) first, because it’s the most interesting part. I didn’t. I forced myself to prove the core banking flows first — account creation, transfers, card management, notifications. Boring, essential, correct.

NeuroOffice only matters if the banking foundation is trustworthy. Order matters.

What “MVP” actually means in fintech. In most SaaS, MVP is the smallest thing that delivers core value. In fintech, MVP is the smallest thing that delivers core value AND passes a security review AND handles edge cases that could cause real financial harm AND has audit trails for every state change.

That’s not optional complexity. That’s the job.

Something I wish I’d understood sooner: the Bank of Lithuania runs a regulatory sandbox — a programme where selected fintechs test innovations in a live environment with real users, under the regulator’s supervision, for up to 6 months. It’s not a shortcut around licensing; it’s a structured way to test with the regulator in the room.

I haven’t gone through it. But reading the selection criteria early would have shaped my design decisions, because it tells you exactly what a regulator wants to see. That’s free information most founders never look at.

Where we are now: MVP built. The flows work - registration, virtual transfers, card freeze/unfreeze. The AI layer is genuinely live: eight NeuroOffice agents running on real models, with testers actively using them.

What we don’t have is live banking infrastructure. No real money, none of the actual banking security stack. That comes with the licence and the funding. The MVP proves the product. The licence makes it real.

I’d rather say that plainly than dress up a prototype as something it isn’t.

Happy to answer questions on any of the technical decisions — especially the compliance architecture. That took the most learning.

—

Andrew, founder of Y-tech Bank. ytechbank.com

Building a robo-advisory engine for a neobank: our approach

Andrew Yakush — Mon, 06 Jul 2026 06:13:02 +0000

Robo-advisory sounds simple until you try building it inside a full banking platform. Here's how we're thinking about it at Y-tech Bank.

A useful robo-advisor isn't just "fill out a risk quiz, get a portfolio." That's a 2015 product. A modern one needs dynamic risk profiling that updates from behaviour instead of a one-time quiz, cross-domain context so investment decisions know about your banking data, awareness of life events so the portfolio adjusts when something changes, micro-investing built into the same flow, and explanations so users understand what the system is doing and why.

Building it inside a neobank gives you a real data advantage. Traditional robo-advisors like Betterment or Wealthify work with isolated investment data — they know your declared income and risk tolerance, and that's about it. A robo-advisor inside a bank can see your verified income from actual deposits, your monthly expense baseline from transaction history, your upcoming large expenses from recurring patterns, your emergency fund status, your business cash flow if you're an SME user, and tax signals like year-end expenses or self-employment patterns.

That changes recommendation quality a lot. If the system knows your rent is due in 4 days and your salary hasn't landed yet, it shouldn't be telling you to invest this week. If your income jumped 30% this month, it can bump up your contribution automatically.

Our architecture has the banking data layer feeding a single real-time financial model of the user, which feeds the investment engine — risk profiling, portfolio construction, rebalancing triggers, the micro-investing flow, and the explainability layer. The key decision: the investment engine reads from the shared user model. It doesn't keep its own separate profile.

Investment services in the EU fall under MiFID II, which adds requirements around suitability, best execution, cost disclosure and appropriateness testing. We're building MiFID II compliance in from the start, which means the explainability layer isn't just nice UX — it's a regulatory requirement.

One feature people underrate: micro-investing. Round-up investing sounds like a gimmick. The data says otherwise. Users who turn on micro-investing invest 3–5x more over a year than users who start investments manually, because removing friction works. Our flow: a transaction completes (say €4.60 coffee), the round-up gets calculated (€0.40), round-ups build up in a buffer, and at a threshold the user sets (say €5) the investment runs automatically. The user watches the portfolio grow alongside their spending, in the same session, same context.

Honest note on what we haven't solved: real-time rebalancing at scale is still a work in progress. The challenge isn't the algorithm — it's executing trades efficiently across thousands of accounts at once without slippage or latency problems. We're looking at execution partnerships for that part.

—

Y-tech Bank is pre-seed. We're building this stack and looking for engineers who want to work on hard fintech problems. ytechbank.com

How AI is actually changing banking (not just the hype)

Andrew Yakush — Fri, 03 Jul 2026 15:44:14 +0000

"AI-powered" might be the most overused phrase in fintech right now. Every bank claims it. For most of them it means they added a support chatbot and called it intelligence.

So let's talk about what real AI in a banking product looks like, and what we're building at Y-tech Bank.

Most current implementations fall into three shallow buckets.

Expense categorization. Your bank sees "McDonald's" and tags it "Food & Dining." Mildly useful. But this is rule-based sorting with an ML wrapper on top. It's automated, not intelligent.

Fraud detection. This one's actually valuable, and most banks have used ML here for years. But it's infrastructure, not a feature — users never see it working.

Chatbots. The most visible and the most annoying. "Hi, I'm Aria, your AI assistant. I can help you check your balance!" No, Aria. You can point me to the balance page.

Real AI in banking should predict things, act before you ask, and connect data across different areas. We're building three layers for that.

The first is personal finance intelligence. This goes past categorization into actual behaviour modelling. The system builds a live financial picture of each user — income patterns, spending rhythms, savings goals, risk tolerance — and uses it to forecast cash flow 30 days out, flag a possible overdraft before it happens, move spare cash into micro-investments automatically, and surface things like "you spent 40% more on subscriptions this month than your six-month average."

The second is NeuroOffice, our AI suite for small businesses. It's a set of agents inside the business banking layer — a marketer, copywriter, HR manager, accountant, lawyer, client manager. Each one has access to the business's real transaction data, so the accountant agent isn't working blind. It sees actual cash flow, real expenses, real revenue trends.

The third is investment intelligence. The robo-advisory layer takes both personal financial signals and market data to build portfolios that fit the user's current financial health, rebalance around life events like a salary change or a big purchase, and explain investment decisions in plain language.

The hard part isn't any single model. It's the shared data layer that lets all three talk to each other in real time. We build it with an event-driven architecture where financial events ripple across every AI surface, one shared user context that all the agents read from, personalization that keeps data inside the platform, and blockchain-backed transaction records for auditability.

The point of AI in banking isn't a better chatbot. It's a platform that actually understands your life and acts on it without you having to manage everything yourself.

That's what we're building. And we're hiring engineers who want to build it with us.

—

Y-tech Bank is a pre-seed fintech. The MVP is live. We're open to , investors and early users. ytechbank.com