Our team is 42. Six of us are human.
Lenders keep asking how a six-person team ships this fast. The honest answer: everyone codes, and a role-specific agent fleet — pointed at four product principles and two decades of lending scars — runs the book of work alongside us.
I have spent a lot of this year in rooms with the people who run lending — CEOs, CTOs and chief risk officers at NBFCs, and the heads of lending service providers. One question comes up almost every time: how do you build and release this fast?
The honest answer surprises people. We are six, including me, and every one of us writes code. But six is not the number that explains the pace. This is.
You know the picture: a few hundred holding a narrow pass against an army many times their size, each one fighting with the training and position of ten. The shape is right. Each of our six engineers commands a full org of role-specific agents — thirty-six of them, counted function by function in the chart below — so six people ship with the reach of a much larger company. The rest of this post is how that org is built, and the one part of it that cannot be copied.
- Everyone codes. All six of us build — no seats that only manage or only advise. Engineering is the condition of working here.
- Six engineers, thirty-six agents. Each engineer commands the whole fleet — CXO agents by role, an advisory board by experience, product and marketing, development and lending-domain SMEs. Any engineer can call any agent.
- A common context layer points every agent at the same goals. The lending domain, the deterministic-core architecture, the brand voice and the four product principles travel with every agent.
- Domain scars are the differentiator, not the agents. Everyone has agents now. Few have two decades of lending scars deciding what the agents build and what they reject.
- End-to-end ownership, human accountability. One engineer carries a problem from pain to released product — scoped with the BMAD framework, every pull request reviewed and merged by a human.
- Four product principles govern the fleet: revenue up, delinquency down, ops cost down, control up — converging on profit per loan disbursed.
Why do lenders keep asking how we ship this fast?
Because their own experience says it should not be possible. The enterprise lending teams these leaders run are large and capable, and they still ship roughly one policy change a quarter. A model goes stale the moment it is live. Collections stay reactive. The cost of operating the book scales with the book. None of that is incompetence — it is the weight of tools built for slow, manual decisioning, and org charts built around them.
So when six people release at a pace they associate with fifty, the instinct is to look for the trick. There is no trick — there is a way of working, and a part of it no one can copy. Both are below.
What does “everyone codes” actually mean at Lokta?
Whatever your title, you build — or you are in the wrong place. We have no layer of people who only write documents about what others should build. The person who understands a lending pain point is the person who ships the fix.
That collapses the distance between understanding a problem and solving it, which is where most software time goes. It is also what makes the fleet useful rather than decorative: agents amplify people who build. Hand the same fleet to a team that only coordinates, and you get faster coordination, not faster shipping.
How is the agent fleet organised?
Like a company — and not the founders’ company, but every engineer’s. Each one calls the whole org below: five CXO agents that decide what to build and why, an advisory board of three that pressure-tests the big calls, a product group of three under the CSO, seven marketing agents under the CMO, ten development agents and eight lending-domain SMEs under the CTO — thirty-six agents in all, the org that builds Lokta’s lending stack.
One detail I would not cut: we named each agent after the best person we have worked with in that seat. The strategy agent is Jesse, the marketing agent is Sam — both named for people who brought a genuinely global perspective to work that otherwise turns parochial. The engineering fleet carries names the same way. When the architect agent makes a call, the name reminds me of the standard the real person held; when we are unsure, the question is simply what would they do? The fleet carries a standard, not just a function.
What is the common context layer every agent shares?
A common context layer. This is the part that turns a set of agents into a team that pulls in one direction. An agent with good prompts but no shared context is a fast stranger. Ours start every task already knowing the things that took us twenty years to learn.
The book, the ledger, the schedule, DPD and NPA classification, co-lending and partner reconciliation — the vocabulary and the failure modes, not a generic CRUD app.
Every agent knows the money-of-record is calculated by code that is right every time, never by a model that guesses, and that agentic AI sits above the deterministic core under governance.
The same brand voice and design bar travel with every agent, so what one ships reads like the rest — whether it is a pricing rule, an API, or this post.
Revenue up, delinquency down, ops cost down, control up. Every agent is measured against the business, not against motion. More on these below.
Keep that context current and shared, and a new agent — or a new engineer — is productive on day one, not month three. It is the same reason a good lending team beats a bigger one: not more people, a tighter shared model of the work.
How does a problem become a release?
The process rewards one thing: end-to-end ownership. An engineer does not hand a problem down a line of specialists — they carry it the whole way, with the fleet doing the heavy lifting at each step.
- Scope the pain. The engineer who owns a problem sits with the lending workflow until they can name where it actually bleeds — not where it looks like it bleeds. We scope it with the BMAD framework, a structured, agent-driven method for turning a problem into a crisp spec, now adapted for the lending domain itself. This is where domain context earns its keep.
- Build a rapid cut. The architect agent shapes it, the AI and backend agents build it, the frontend agent makes it usable. Days, not a quarter.
- Validate inside and out. The quality and security agents stress it; then real lending operators and external domain experts see it before any customer does. Better wrong in a review than in production.
- Ship the minimum lovable product. Not the minimum viable one — the smallest thing a lender would be glad to use, built to the four principles from the first line.
- Release and feed it back. Every release instruments its own outcomes, so the next pass starts smarter. The loop that makes a loan book learn makes our product learn.
One person, accountable from the pain to the release. The last step is always human: every change ships as a pull request an engineer reviews and merges. The agents do the work; an engineer reads it, signs it off, and owns it. There is no “the AI did it” here. The fleet is what lets one engineer carry a problem the whole way without it taking a quarter.
If every startup has agents now, what is actually different?
This is the part that is not the agents. By 2026, a small team shipping fast with AI is not rare — role-specific agents, a context layer, an ownership culture, plenty of good startups have some version. If that were the whole story, our pace would not be a moat, and the lenders asking the question would catch up.
The difference is what drives the process, not the process.
The agents are the commodity. The judgment behind them is not.
What they cannot buy is two decades of running loan books under regulation, where the ledger has to tie out to the rupee and being approximately right is not good enough.
Ours inherit the scars — the clever policy that quietly grew the wrong book, the integration that capped lending velocity, the audit that failed on memory rather than conduct. The fleet avoids them because we lived them.
Two decades of lending scars, encoded into every agent’s shared context. That is the part no one can copy in a quarter — and it is why the team behind Apache Fineract can hand a six-person company the reach of a far larger one.
This is the real reason the pace holds. Speed without domain judgment produces a lot of well-built things pointed at the wrong target. We have built those things before — with real lenders and real money — and encoded the lesson. The agents move fast; the scars keep them pointed the right way.
What are Lokta’s four product principles?
They are the second half of why the fleet stays aligned. Every agent and every engineer points at the same four outcomes, so a faster team does not mean faster motion — it means faster movement toward the things that make a lender money.
| Principle | What every agent optimises for | The number it moves |
|---|---|---|
| Revenue up | More good loans approved, priced to risk, won from the field. | Yield · approval rate on creditworthy applicants. |
| Delinquency down | Sharper risk reads, earlier warning, smarter collections. | DPD · credit cost. |
| Ops cost down | Work the fleet runs end to end, so cost stops scaling with the book. | Cost-to-serve per account. |
| Control up | Audit-by-design and maker-checker, shipped by default. | Provable decisions · clean audits. |
All four converge on a single headline we hold the whole company to: profit per loan disbursed — not how much we help a lender lend, but how much they keep on every loan they put out. An agent that ships fast but moves none of these four has done nothing useful. That rule, more than any prompt, keeps the fleet honest.
Can six people really run a lending stack?
The pace is real, and it is not magic. It is six people who all build, a fleet organised like a company, a context layer that carries two decades of lending into every task, and a process that hands one engineer a problem and the means to finish it. The agents are the visible part. The judgment underneath — what to build, what to refuse, the four principles every release answers to — took twenty years and cannot be cloned in a quarter. That is the answer I give in those rooms. It tends to change the next question.
One last thing, because it matters more than the fleet: there is no alternative to human ingenuity. The agents are leverage, not replacement — they amplify people who build, and they are useless without them. So over the coming months we will hand-pick the humans who join this team, with the same care we built the fleet. Six is where we start, not where we stop. The agents scale the work; the humans are still the point.
Frequently asked questions
How does a six-person team ship lending software this fast?
Everyone codes, and everyone commands an agent fleet. All six of us build — no seats that only manage or advise. Each engineer owns a problem end to end, from where a lending workflow bleeds to a released minimum lovable product, with thirty-six role-specific agents doing the heavy lifting. An engineer reviews and merges every pull request, so accountability stays human. Pace comes from ownership plus context, not headcount.
What is an agent fleet, and how is it organised?
Thirty-six role-specific AI agents, organised like a company that every engineer can call. Five CXO agents carry strategy, technology, finance, brand and revenue; three advisory agents pressure-test the big calls; a product group of three reports to the CSO; seven marketing agents report to the CMO; ten development and eight lending-domain SME agents report to the CTO. The access model is the point: not the founders, but each engineer commands the whole org.
Every startup uses AI agents now — what actually makes Lokta different?
The agents are the commodity — anyone can buy the same models. What they cannot buy is two decades of running loan books under regulation, where the ledger has to tie out to the rupee and a clever policy can quietly grow the wrong book. That domain expertise, and the scars under it, is encoded into the fleet’s shared context. An agent with no lending judgment ships confident slop; ours inherit the judgment, which is why what they build points at profit per loan disbursed, not motion.
What are Lokta’s four product principles?
Revenue up, delinquency down, ops cost down, control up — converging on one headline: profit per loan disbursed. Revenue up is more good loans, priced to risk. Delinquency down is sharper risk reads, earlier warning, smarter collections. Ops cost down is the fleet running work end to end, so cost stops scaling with the book. Control up is audit-by-design and maker-checker, so speed never costs governance. The four keep the agents aligned to the business, not just busy.
What is the BMAD framework?
BMAD is a structured, agent-driven method for turning a problem into a crisp product spec — how we scope and define what to build before any code is written. At Lokta we run product definition and scoping through BMAD, and we are now adapting it for the lending domain itself, so scoping carries the same lending context as the rest of the fleet.
How many AI agents does Lokta use?
Thirty-six role-specific AI agents, used by a six-person engineering team. They are organised like a company: five CXO agents, three advisory agents, a three-person product group, seven marketing agents under the CMO, and ten development plus eight lending-domain SME agents under the CTO. Every engineer can call any agent, and an engineer reviews and merges everything the agents produce.
Read next:
- The loan book that learns — the same feedback loop that makes our product learn, turned on a lender’s book.
- AI in lending: why a deterministic core — the three-layer architecture every agent in the fleet is built on.
- What we learned building Fineract, and why we started over — where the two decades of scars come from.
Chandramouli is co-founder of Lokta. He works with a six-person team and an agent fleet to build the AI-native lending stack — on a core you can own, change, govern, and prove — and is on LinkedIn for lenders who want to build it with us.
