Short answer
RaftLabs built a US fintech a working proof of concept, UPIP, where an AI agent is the primary interface across both brokerage accounts and crypto wallets. Two engineers and a project manager delivered it in roughly 10 weeks, using one normalised holding model and around 42 scoped agent tools.
Engagement
The UPIP engagement
- Client
- A financial media and research company in Florida, United States, around 150 employees. Not named here pending approval
- Sector
- FinTech, with a fundraising problem rather than a software problem
- Delivery
- Proof of concept, roughly 10 weeks start to finish
- Team
- Two engineers and one project manager
- Scope
- Unified portfolio across brokerage accounts and crypto wallets, an AI agent as the primary interface with around 42 scoped tools, a performance analytics engine, and a confirm-before-execute trade safety layer
- Status
- POC delivered and accepted. The investor pitch has not happened yet, so there are no commercial outcomes to report
The client had the idea fully formed. One platform where your brokerage holdings and your on-chain assets sit in the same view, and where you talk to an AI agent instead of learning a dashboard. Traditional finance and decentralised finance, one surface, conversational.
What they didn't have was anything to show. The team that could have built it internally was busy shipping the core business, and a slide deck describing an AI-first investing platform reads exactly like every other slide deck describing an AI-first investing platform. Without a working artifact, the decision-maker couldn't pitch it, couldn't raise against it, and couldn't get internal buy-in to take it further.
That's the whole brief. Not "build us a product". Build us something real enough to put in front of an investor, in the window we have.
We delivered a working proof of concept in roughly ten weeks with two engineers and a project manager. The interesting parts are the three decisions that made ten weeks possible: one data model for two very different asset classes, an agent built as a set of scoped tools rather than an open-ended chatbot, and a feature we recommended cutting in the first fortnight.
before & after
From a vision on paper to something an investor can use
- A clear, well-understood idea with nothing demoable behind it
- An internal team too committed to the core business to build it
- No evidence that brokerage assets and on-chain assets could sit in one coherent model
- No evidence that an AI agent could be a safe primary interface for something that moves money
- A fundraising window running down, with the pitch blocked on the artifact
- A working POC where stocks, ETFs, options, tokens and staked assets all behave the same way downstream
- An AI agent as the primary interface, backed by around 42 scoped tools rather than free-form chat
- An institutional-grade performance analytics engine with benchmark comparison against SPY, QQQ and GLD
- A confirm-before-execute safety layer and audit logging on anything that places an order
- Model-agnostic routing, so the underlying model can be swapped without a rewrite
- A demoable artifact the decision-maker can take into an investor conversation
The problems we had to solve
- 01
Making a share of Apple and a staked token behave like the same kind of thing
A brokerage position and an on-chain position have almost nothing in common at the data level. Different identifiers, different price sources, different notions of quantity, different settlement, different everything. If that difference leaks upward, every feature above it has to handle two cases forever, and a ten-week build becomes a six-month one.
We considered keeping the two worlds separate all the way up and reconciling only at the presentation layer. It's faster to start and it's a trap: aggregation, allocation and analytics all then need asset-class branches.
We went the other way. A single normalised holding model, with per-provider adapters underneath it, SnapTrade for brokerage accounts and thirdweb for wallets. Each adapter's only job is to turn what its provider returns into that one shape. Above the model, aggregation, allocation and analytics services never ask what kind of asset they're looking at.
The result is the reason the timeline held. Every feature we built after that point worked across both asset classes on the day it shipped, because there was only one path through the code.
- 02
Institutional-grade analytics without writing an analytics library
The platform needed real performance analytics, not a line chart. Risk-adjusted returns, drawdowns, benchmark comparison, the metrics an investor would expect to interrogate during a demo. Writing that from scratch is a project on its own and would have eaten the whole engagement.
We built on quantstats-js rather than reimplementing the maths. What that decision actually bought us was less than it looks like on paper, and it's worth being straight about it. The library is untyped, which in a TypeScript codebase means you are writing the safety yourself. We ended up with a substantial wrapper around it: data normalisation on the way in, period filtering, benchmark fetching and caching for SPY, QQQ and GLD, custom fifteen-day returns, metrics tables, SVG chart generation and full tearsheets.
The trade still came out right. We wrote integration code, which we understand and can debug, instead of financial mathematics, which we would have had to verify. But anyone budgeting a build like this should price the wrapper, not just the library.
- 03
An AI agent that can place trades, without an AI agent that can place trades by accident
This is the decision we're most proud of on the project. The moment a conversational agent sits in front of a brokerage account, the failure mode stops being an unhelpful answer and starts being an unintended order.
We didn't build an open-ended assistant with access to an API. We built roughly 42 individually scoped tools, each one doing a single defined thing, and put a strict safety layer in front of anything with consequences. Actions that move money require explicit confirmation before execution, and everything is audit logged. The agent's power comes from the breadth of tools it can reach, not from how much latitude it has with any one of them.
The same layer carries the unglamorous work that financial integrations always turn out to need: permission checks on the brokerage side for whether an account is options-enabled and has buying power, duplicate position detection when the same holding appears across accounts, and on the wallet side, swaps, bridges, gas handling and token address resolution.
- 04
Getting the model to reliably return both an answer and a correct tool call
This was the surprise, and it's the one we'd warn anyone else about. The architecture was sound and the tools worked. What repeatedly failed was model behaviour: getting it to always return both a human-readable response and correctly structured tool output, every time, rather than one or the other.
There is no elegant fix we can report. It took an unusually emphatic system prompt, around 900 lines, built on mandatory rules rather than guidance. That is not a flattering number and we're publishing it deliberately, because plans for agent projects routinely allocate time to tools and integrations and almost none to making the model behave consistently at the boundary between prose and structured output.
We paired it with model-agnostic routing through OpenRouter, which means the underlying model can be changed without touching the application. On a build where reliability varies by model and the good option changes every few months, that flexibility is worth more than picking the best model on day one.
the build
How we worked, and what we argued about
We recommended cutting a feature in the first fortnight
The original scope included community comparison: showing a user how their portfolio stacked up against everyone else's. It's a good feature in a live product and it is meaningless in a proof of concept, because there is no community. Comparing a user against a handful of test accounts produces a number that is worse than no number, and in a demo it invites exactly the question you don't want.
We recommended dropping it and the client agreed. That cut is a large part of why ten weeks was enough.
We trimmed scope again when production credentials weren't available
We didn't have live production API access for the brokerage and Web3 providers during the build. Rather than pretend otherwise, we said plainly which parts would stay sandboxed or limited, and reshaped the scope around what could be genuinely proven.
A POC's job is to be credible, and credibility survives a stated limitation far better than it survives a discovered one during a demo.
Discovery was technical, because the client already knew the business
The decision-maker understood the domain and the market better than we did, and was technical enough to follow architecture discussions in detail. So our diagnosis phase wasn't about uncovering business insight they lacked. It was feasibility work: what can actually be unified, what the providers really return, what an agent can reliably be trusted with.
That shapes how you run the engagement. With a technical buyer who owns the vision, the value you add is judgement about what's buildable in the window, not a rediscovery of their own market.
Three people, ten weeks, no drama
Two engineers and a project manager, start to finish. The scope was held deliberately tight and the architecture decisions were made early, which is what let a team that size ship something this broad. The delivery team's own retrospective on what they'd do differently was, in substance, nothing material.
Proof
What we can and can't claim
This is a proof of concept and the client had not yet pitched investors at the time of writing. There are no revenue figures, no user numbers and no measured before-and-after data, because none exist yet. What follows is what was delivered and how it was judged.
| Result | What changed | Period or context | Evidence and limitation |
|---|---|---|---|
| What shipped | A working, demoable unified portfolio POC with an AI agent as the primary interface | Full POC scope, minus the community comparison feature we recommended cutting | Delivery team questionnaire answers, June 2026 |
| Time to a fundable artifact | Roughly 10 weeks from engagement start to accepted POC | Two engineers and one project manager throughout | Delivery team questionnaire answers, June 2026 |
| Agent surface | Around 42 scoped tools behind one conversational interface, with confirmation required before any executing action | Inferred from the codebase by the delivery team rather than counted from a spec | Delivery team questionnaire answers, June 2026, labelled by them as code-inferred |
| Asset coverage | Stocks, ETFs, options, tokens and staked assets handled through one normalised holding model | Brokerage data via SnapTrade, wallet data via thirdweb, both behind the same downstream services | Delivery team questionnaire answers, June 2026 |
| Client acceptance | Client satisfied with the delivered build and accepted it | On delivery, at the end of the roughly 10-week engagement | Delivery team questionnaire answers, June 2026. No formal testimonial has been recorded and no exact quote was captured |
| Commercial outcome | None yet | The investor pitch the POC was built for had not taken place at the time of writing | Delivery team questionnaire answers, June 2026. Engagement is paused pending that pitch |
The lesson
You do not need production access, or a production product, to unlock a fundraise
If you're a fintech sitting on an idea you can't get funded, the instinct is to make the spec bigger. More surface area, more features, more of the eventual product, on the theory that investors fund completeness.
They don't. They fund credibility, and credibility comes from a working artifact that survives being poked at. This engagement produced one in about ten weeks with three people, without live production API credentials, and while deliberately deleting a feature from the original scope. Those constraints didn't damage the POC. Cutting community comparison made it more credible, not less, because a comparison against an empty community is the kind of detail a sharp investor finds in the first five minutes.
The three choices that made it work generalise well beyond this project. Normalise your data model early, before feature work starts multiplying the branches. Give an AI agent many narrow tools rather than broad latitude, especially when it touches money, and make confirmation mandatory on anything with consequences. Stay model-agnostic, because the best model today is not the best model in six months and you don't want that decision welded into your application.
And budget real time for model reliability. The tools and integrations behave predictably. Getting a model to return the right shape of output every single time is the part that quietly eats weeks.
Where to go next
What we would recommend next
These are opportunities beyond the delivered POC, not work that was included.
- Next 01
Run the investor pitch and capture what gets asked
The POC exists to be demoed and hasn't been yet. The questions an investor asks in that room are the highest-value product input available, and they will be more useful than any internal roadmap session.
- Next 02
Move from sandbox to live provider credentials
Parts of the build stayed sandboxed because production API access wasn't available. Getting live credentials turns several stated limitations into demonstrated capability, and it's the cheapest available upgrade to credibility.
- Next 03
Harden the agent's reliability envelope before real users
The 900-line system prompt carries reliability today. Before real money and real users, that belongs in tested guardrails with evaluation coverage, so behaviour is measured rather than asserted.
- Next 04
Revisit community comparison once there is a community
It was the right cut for a POC and it's a genuinely good feature in a live product. It should come back the moment there's a user base large enough for the comparison to mean something.
Evidence and limitations
Reviewed 22 September 2026
- Everything here comes from one source: the delivery team's written answers to our case study questionnaire, recorded in Asana on 16 June 2026. It has not been cross-checked against a second account.
- Several technical details are code-inferred, including the tool count of around 42 and the system prompt length. The delivery team labelled them as such and we have kept that label rather than presenting them as specified figures.
- There are no outcome numbers, because none were measured. This was a proof of concept, the investor pitch had not happened, and no commercial or usage data exists.
- Budget is not stated. The delivery team did not know the commercial terms, and we would rather omit it than guess a shape. The engagement model is stated as a proof of concept build for the same reason.
- No client testimonial has been recorded. The delivery team reports the client was satisfied. No exact quote was captured and we have not manufactured one.
- The client is not named on this page. They are described by sector, country and size only. The product is pre-pitch, and naming should wait for explicit written approval.
- Client sign-off on this page is pending. It should not be published before the client has approved the account of the engagement, and separately approved being named if that changes.
Questions buyers ask about AI agent POCs like this
Roughly ten weeks from start to an accepted proof of concept, delivered by two engineers and one project manager. It was scoped as a POC rather than a product, and one feature was cut in the first fortnight to protect that timeline. Budget shape was not disclosed to the delivery team, so we don't state it.
Enough working surface that a sharp person can poke at it without hitting a wall. Here that meant real unified data across both asset classes, analytics an investor would recognise, and an agent that genuinely executes. It did not need production credentials, a community feature or production-scale infrastructure. Credibility beats completeness.
Narrow scope and mandatory confirmation. We built around 42 individually scoped tools rather than giving one agent broad API access, and put a safety layer in front of every executing action so nothing that moves money happens without explicit confirmation. Everything is audit logged, and permission checks run first, for example whether an account is options-enabled and has buying power.
One normalised holding model, with per-provider adapters feeding it. We used SnapTrade for brokerage accounts and thirdweb for wallets, and each adapter's only job is to produce that shared shape. Aggregation, allocation and analytics then never branch on asset class, which is what keeps stocks, ETFs, options, tokens and staked assets behaving identically downstream.
Model reliability. Getting the model to consistently return both a readable response and correctly structured tool output took an emphatic system prompt of around 900 lines built on mandatory rules. The architecture and integrations behaved predictably. Behaviour at the prose-to-structured-output boundary did not, and most project plans under-budget that entirely.
Because the best model changes faster than the application should. Model-agnostic routing let us swap between providers and models without rewriting anything, which mattered on a build where reliability varied noticeably by model. On a POC that may sit paused for months before its next phase, not welding a model choice into the code is straightforwardly worth it.
Community comparison, which shows a user how their portfolio performs against everyone else's. In a POC there is no community, so the number would have been meaningless and a demo question waiting to happen. Parts of the provider integration also stayed sandboxed because live production credentials weren't available during the build, and we said so rather than working around it.
The pattern transfers wherever fragmented data sources need one coherent view and a conversational interface over them. Wealth management, treasury, insurance and logistics all have that shape. What transfers is the normalised data model, the scoped-tool agent architecture and the confirm-before-execute safety layer. What doesn't is the specific providers and the domain analytics.
The engagement is paused, by agreement. The POC was built to enable an investor pitch and that pitch hasn't happened yet. A further phase depends on how it goes, which is the correct sequence rather than a stalled relationship.
Related work
