Partner cheat-sheet · Financial services
OneDroid Partner
Sales Guide
For partners and contacts introducing OneDroid to brokers, asset managers, FCMs and capital-markets firms. Written for people with relationships, not product training.
Read this part if you read nothing else
- The one idea — lead with this, always
- "When a frontier model is just an API call away, context is the moat."
Your competitors buy the same models, on the same terms, with the same API key. The model is a brain in a jar — swappable, and getting cheaper. What it knows about their business is not, and it is the only part nobody else can buy.
That knowledge is context, and context is three concrete things: access to your data, access to your tools, and memory that persists. OneDroid is where those three live, governed.
Say "context," not "context engineering." Engineering is a process, and processes are hireable. The asset is the context itself, and it compounds. - What OneDroid is
- Two products, and they map onto that sentence exactly. OneDroid Synapse is the governed gateway — access to your data and your tools, with every call authenticated, policy-checked and logged, fail-open, to an audit log you own. OneDroid Engram is the memory — portable, persistent, permissioned context. Deployed in the firm's own cloud, they are where the firm's context lives.
- Your one-liner
- "Everyone can buy the same models. Nobody else can buy what yours knows about your business. OneDroid is where that context lives — your data, your tools, and memory that persists — governed, in your own cloud, so your AI team ships instead of rebuilding plumbing."
- The security-audience variant — keep it in your pocket
- "Every firm now has employees using AI on accounts IT can't see. OneDroid puts all of it through one gateway inside your own cloud — gated, scanned, and on a tamper-evident audit trail. The question stops being 'do we trust AI' and becomes 'here's the record.'"
Use this only with a CISO or a Chief Compliance Officer. It lands hard there and badly with the AI team, who hear a tax rather than a capability. See §4. - The build-vs-buy answer
- Concede the easy part in the first sentence — "an MCP proxy is a weekend; if that's all this were, build it" — then move the argument to where it actually lives. The plumbing isn't the hard part. The plumbing that passes review is. What a reviewer asks, and what each answer costs to build:
Any one of those is a sprint. All of them, tested, and defensible in front of an examiner, is the two quarters — two quarters of your AI team not building the thing you hired them for.
They ask You have to have built "Whose credentials is the agent using?" Credentials bound per user, per workspace, per account — AES-256-GCM at rest, individually revocable, never in a connection string. Not one shared service account carrying everyone's access. "What can this agent reach, and who decided?" Tool-level allow/deny policy, recorded at the time the decision was made — not reconstructed from logs afterwards. "Show me last quarter's AI access to client data." An append-only event log you own, queryable, with retention you set. "How do I know the log wasn't edited?" The expensive one. Hash chain, Merkle tree, canonical serialisation, a transactional outbox so writes can't be lost, a reconciler, a circuit breaker — and an independent verifier, because a system attesting to itself proves nothing. The reference implementation is 25 files, 12 of them tests. "What stops client PII reaching the model?" Detection in the request path, returning a redaction reference for audit — not a nightly batch job. And tuned: ours excludes date patterns from free-text lanes, because specification documents are full of dates. "Which third parties see this?" A subprocessor list you are willing to publish, including the answer for embeddings. "What happens when we leave?" Data in your own Postgres. Export is a SQL query.
Two rules when you use this. Never argue the integration is difficult — a good architect knows it isn't, and you lose the room. And never claim these controls are enforcing in their deployment on day one; see ban #10 and route capability questions to Michal. - Your ask is not a meeting
- It is: "Want me to forward the case study?" The reader self-selects. No meeting ask in a first touch — that's the standing rule, and it's why these emails get replies.
- Who to call first
- The AI organisation — AI Solution Architect, AI Transformation Officer, Chief AI Officer, Head of Applied AI. Not security, not compliance. Those are the gates you clear later, not the door you knock on. See §5.
- The one thing you must never say
- "All your data stays inside your environment." It is false — for us and for every AI vendor on earth, because model inference is an outbound call. Saying it gets you killed by the first engineer who reads the architecture. The accurate version is in §7, and it is stronger.
01What we actually sell — it is narrower than you think
| Thing | What it is | Commercial status |
|---|---|---|
| OneDroid Synapse | The governance gateway. Every AI/agent tool call passes through it. Sees, gates and records everything. | Product. Free to use; enterprise when you need the grade. |
| OneDroid Engram | Governed agent memory — what agents are allowed to remember, searchable and audited. | Product. Same model. |
| The Dark Factory method | The six-stage process for building software with AI agents under an adversary review gate. | Open source. Free. Not a product. |
| Implementation help | Getting the above adopted inside a real firm. | This is the paid engagement. |
The tools are free; the process, implementation and method are ours — and we sell help adopting it. The only products are OneDroid Synapse and OneDroid Engram.
OneDroid Synapse and OneDroid Engram are the only things you may call products. If you find yourself naming a third, stop and check first.
Do not quote pricing. Not a range, not a "starts around." It depends on tier, deployment and scope. Say "depends on deployment and scope — Michal will walk them through it" and hand off.
What we sell is visibility and accountability — not guarantees
We don't sell guarantees. We sell visibility and accountability. We can't guarantee an AI tool is safe. We can tell you exactly who built it and who operates it, what it does inside, which codebase it runs, and which data it received and sent back.
This is also the legal posture, live at onedroid.ai/terms §5 — "agents act for you, not for us." The gateway is deliberately mechanical: we transport, authorize and log tool calls; we do not review them, decide them, or vouch for their outcomes.
Why this helps rather than weakens the pitch: every AI vendor is promising safety they cannot evidence, and sophisticated risk people have stopped believing it. Selling proof instead of promises is differentiated, survives diligence, and matches what a compliance function can actually act on. Never upgrade it into a safety guarantee to close a deal — that contradicts our own terms of service.
02Why financial services — first the AI team, then the gates
The AI team's problem — lead with this
Every firm in this sector now has AI activity and a growing list of things that haven't shipped. The reasons repeat:
- The integration is rebuilt every time. Each new agent needs its own connectors, credentials and permissions. The tenth use case costs as much as the first.
- Context doesn't survive. Knowledge lives in whichever tool produced it, so it gets re-pasted and re-explained, and nothing compounds.
- Every use case queues for review. Security and compliance see each one as a new thing to assess, because it is.
- Model choice feels like a one-way door. Nobody wants to commit the firm to a vendor in a market that reprices every quarter.
OneDroid answers all four with the same move: put the integration and the context in one governed place, and the agents become cheap and interchangeable. That is the pitch to an AI leader — and it happens to produce the evidence the control functions need.
Then the gates — what makes it urgent, not what makes it attractive
How the hell can I control what people connect their agents to? What data does it send? Is it compliant? Is it safe?
The control-side problem is real. This is shadow IT, agent edition — and in a regulated shop it is worse than in a normal company, for five reasons you can name:
| The gap | What it sounds like on their side |
|---|---|
| Supervision | Their supervisory obligations cover communications and business records. An analyst's ChatGPT session is neither captured nor reviewable. Nobody designed that hole; it just opened. |
| Books and records | Retention and audit-trail obligations assume records exist. AI interactions on personal accounts produce no record at all — not a bad record, none. |
| MNPI / information barriers | Research, positions and client flow pasted into a consumer AI account walk straight through every information barrier the firm built. |
| Client PII | Privacy obligations attach to customer information regardless of which browser tab it left through. |
| Third-party resilience | EU-facing entities now carry formal ICT third-party risk obligations. "We have an acceptable-use policy" is not an answer to a regulator or a bank counterparty's security review. |
Do not argue regulation with them. You are not their compliance officer, and rule-number ping-pong loses deals. Ask the question and let their compliance team supply the rule numbers:
"If your regulator asked which client data your AI tools touched last quarter, through which account and on whose authority — how long would it take to answer?"
The silence is the sale.
03When a frontier model is just an API call away, context is the moat
This is the section that lands with an AI leader, a CIO or a head of strategy, and it reframes the conversation from cost-of-compliance to competitive advantage. Three ideas, in order.
When a frontier model is just an API call away, context is the moat. Your competitors buy the same models, on the same terms, with the same API key. What your model knows about your business is the part they cannot buy.
Engineering is a process, and processes are hireable — a competitor can staff up and copy the practice in two quarters. The asset is the context itself, and it compounds. That distinction is the whole argument; don't blur it.
1 — Your data stays yours, and that is the differentiator
What no competitor can copy is the firm's own data, context and institutional knowledge. OneDroid's job is to make that context available to AI on the firm's terms — curated, governed, scoped to each use case, and never surrendered to a vendor as the price of using their model. The data stays with the company and becomes the moat, rather than becoming someone else's training advantage.
Context, concretely, is three things: access to your data, access to your tools, and memory that persists. OneDroid Synapse provides the first two; OneDroid Engram provides the third. That is the whole product line in one sentence.
2 — Which makes the agent a brain in a jar
Think of OneDroid Synapse as a USB hub. Every tool, system and data source plugs into the hub once. The agent — whatever harness it runs in, whatever model sits behind it — plugs into the other side with a token.
Your developers use Claude Code today. Tomorrow they use Codex. You connect it to OneDroid Synapse, and everything else is already connected: same tools, same credentials, same permissions, same audit trail. Nothing gets rebuilt. The same holds for any agent the firm builds itself — give it a token, and it doesn't matter which harness or model is underneath.
You integrate once — with the hub, not with a model vendor.
3 — So picking OpenAI or Anthropic today is not lock-in
The expensive part of an AI stack was never the model. It is the integration — the connectors, the credentials, the permissions, the audit plumbing. Once that lives in the hub, the harness and the model are both the cheap, swappable end. A better or cheaper model ships next quarter, you point an agent at it, and the tools-and-data layer doesn't move.
Which is why "which AI vendor should we standardise on?" is the wrong question. The right one is "where does our integration live?"
Open-source models: an option they can test — not a recommendation
Say it in exactly those words. Open-source models are not a silver bullet. They may work well for a given workload; they may not. The point is that OneDroid turns the question into a measurable experiment instead of a strategic bet — decided on the firm's own numbers rather than on any vendor's claims.
Because the tools-and-data layer sits in the hub, trying one costs almost nothing:
- Safe — point an agent running an open-source model at the same governed tools. The policy and audit trail don't change. Stop using it and you are exactly where you started.
- Easy — no re-integration. The connectors, credentials and permissions are already in the hub.
- Measurable — run the same scenario suite like-for-like and compare cost, latency and quality on your own workloads.
- Transparent — the same detection gate and audit trail apply whichever agent does the work.
That open source is cheaper, good enough, or the right answer. Where open source suffices, where a frontier model earns its transit, and the real GPU and operations cost are open questions that measurement answers. A hybrid split is the likely shape, but it must fall out of the numbers rather than be asserted.
Partners who oversell this lose the room to the first engineer who has actually tried to run one.
04The 30-second pitch
Say it in this order. The order matters — pain, mechanism, proof, ask.
"Your AI team already has the models. What they don't have is one place to plug in the tools and the data — so every new agent redoes the same integration, context resets between tools, and each use case waits its turn in security review.
OneDroid Synapse is that one place. Connect your systems once and every agent your team builds inherits the whole surface with a token. OneDroid Engram holds the context so it survives a change of model or client.
And because the gateway sits in the call path from day one, the security and supervision answers already exist when someone asks for them — which is usually what actually unblocks the programme.
They proved it in a regulated healthcare setting — two quarters from 'can we even use AI here' to a running, audited platform.
Want me to forward the case study? It's the unusual kind that publishes the failures."
Governance sold as the point is a tax nobody volunteers for, and it puts you in front of the wrong person. Lead with what the AI team gets, and the compliance story arrives as a property of the platform rather than the reason to buy it.
Keep the shadow-AI opener — "every firm now has people using AI on accounts nobody can see" — in your pocket for a security or compliance audience. It lands hard there and badly everywhere else.
"And the part most people miss: everyone can buy the same models. What they can't buy is your data. Think of this as a USB hub — your tools, systems and permissions plug in once, and whatever agent your teams use plugs into the other side with a token. Your devs are on Claude Code today; if they move to Codex tomorrow, everything else is already connected. That's why choosing a model vendor now isn't a lock-in decision — and why you can actually test an open-source model instead of just arguing about one."
05Talk tracks by who you're sitting with
Start with the AI organisation, not the control functions. Security and compliance do not fund an AI platform — they approve or block one. Lead with them and you are selling a tax to someone whose job is to say no. Lead with the AI team and you arrive at security with a champion, a use case, and a design that already answers their questions.
Buy — start here
| Buyer | What they actually care about | Open with |
|---|---|---|
| AI Solution Architect | Not rebuilding the same integration for every agent. Where context lives. Not being locked to one model. | "How many times has your team wired up the same tool for a different agent?" |
| AI Transformation Officer | Use cases reaching production instead of stalling. Something that scales past the pilot. | "How many of your AI pilots have made it into production — and what stopped the rest?" |
| Chief AI Officer | A platform strategy that survives the model market. Whether AI spend builds an asset or rents one. | "If a better or cheaper model ships next quarter, how long would it take you to move?" |
| Head of Applied AI / Data | They already built agents. They need the layer that gets them past risk committee. | "You've got the models and the agents. What's between them and your data?" |
Then clear — you will meet these, and you need them
| Gatekeeper | What they need to see | How to hand off |
|---|---|---|
| CISO / Head of InfoSec | Egress, credential custody, what AI can reach, surviving a client's security review. | "The gateway is already in the call path — the egress answer exists, let me get you the detail." |
| Chief Compliance Officer | Supervision, retention, provable records, exam readiness. | "Every call is on a tamper-evident record. Here's what an examiner would see." |
| Head of Technology / Ops | Where it runs, who operates it, what happens on exit. | "Your cloud, your Postgres, export is a SQL query." |
Firms that fit best already have AI in flight — an internal assistant, an Applied AI team, a copilot rollout — and a compliance function with teeth. The pitch is not "adopt AI." It is "you already did; here's the layer that makes the next ten use cases cheap." Firms with no AI activity at all are a longer, worse conversation.
06The proof you may use
One asset, deliberately failure-forward: "Governed AI for Regulated Clinical Data" (August 2026). Client identity withheld; figures reproducible under NDA.
Why a healthcare case study sells to a broker: the regulatory shape is identical — sensitive data, unforgiving external audits, customers who run their own security reviews. Say that plainly rather than hoping nobody notices.
- The AI assistant invented a mandatory compliance field that did not exist, and reported a list as 6 items when the correct answer was 26. QA's ground-truth cross-check caught it, marked the scenario FAIL, and it never shipped.
- The QA verdict table, published as-is: 16 scenarios — 6 pass, 3 fail, 5 conditional.
- An independent verifier re-derived 21 load-bearing claims and refuted 4. Each was corrected at source before publication.
- The client asked us to claim all data stays inside their environment. We checked. It was false. We refused and wrote the accurate version instead — and that version survived their security review.
- The sensitive-data detection fired on our own traffic, twice, while the final report was being written — each time returning a redaction reference.
Citable numbers: two quarters from standstill to running platform · 126 epics resolved · ~30% of source files are tests.
Why lead with failures. Nobody at a fund believes a case study that shows only wins — it reads as marketing. Publishing the FAILs is what makes the passes carry weight, and it is the same standard they apply to a PM's track record. If a prospect probes any of these hooks, the story deepens rather than collapses. That is the whole design.
07Objections you will actually get
"We already have an AI acceptable-use policy."
That's a rule. This is a record. A policy tells people what not to do; it doesn't tell you what happened. Ask your team to produce last quarter's AI activity against client data — the gap shows up immediately.
"We're covered — we bought ChatGPT Enterprise / Copilot."
That governs one vendor's surface. It doesn't cover the agents your engineers built, the MCP servers they connected, other model providers, or anything on personal accounts. OneDroid sits in the call path for all of it, which is the only place a complete record can exist.
"Can our data stay inside our environment?" Handle carefully
The gateway, the scanning, the audit trail and the work itself run inside your own cloud, and the data comes to rest inside your boundary. Model inference is an outbound call — true for every organisation using commercial AI, no exceptions. So the honest framing is: the data plane and the inference plane are separated, and the call that transits is gated, scanned and logged. Never upgrade this to "nothing leaves."
"Does our data touch any third parties?" Answer precisely
Yes, and they're named publicly on onedroid.ai/privacy rather than buried — AWS, Azure, Supabase, Clerk, Vercel, Google Workspace, and OpenAI for OneDroid Engram's embeddings. That last one matters if they're evaluating OneDroid Engram, so raise it before their diligence team finds it. Naming subprocessors openly is a strength in a vendor review; being caught omitting one is fatal.
"So you can read our traffic?"
The audit log is designed to record the fact and shape of a call, and we hash rather than store sensitive content. What we don't claim is that no fragment could ever surface in error telemetry — that's stated plainly in our own privacy page. Anyone claiming absolute non-visibility hasn't operated a real system.
"Aren't we just locking ourselves into you instead of into OpenAI?"
Fair challenge — ask what each party holds. A model vendor holds your context and your integration, which is what makes leaving expensive. Here the tools, credentials, permissions and audit trail sit in your own cloud, the connection is a standard protocol any client can speak, the method is open source, and your data is in your database. Compare what your exit looks like in both arrangements; that's the honest test.
"Could we run open-source models instead?"
You could test them — and that's the right verb. Open source isn't automatically cheaper or good enough; it depends entirely on the workload. What this gives you is a cheap way to find out on your own numbers: because your tools, credentials and permissions live in the hub rather than in the agent, you can point a different agent or model at exactly the same governed surface, run the same scenarios, and compare cost, latency and quality. The answer is usually a hybrid — but it should come from measurement rather than anyone's opinion.
"Will it stop the AI from doing something wrong?"
It gates what the AI can reach and records what it did. It doesn't vouch for the AI's judgement — nobody's product does, and ours says so in its terms. What caught the invented compliance field in the case study was the review process, not the gateway. That's why we sell the method alongside the platform.
"Isn't this just a proxy? We could build it." Expect this from a good architect
You could, and the proxy part genuinely is a weekend — so say that first, or you sound like you're defending a moat you don't have. Then move it: the plumbing isn't the hard part, the plumbing that passes review is.
Walk the checklist in the lead block — credential binding per user and per workspace, policy recorded at decision time, an append-only log with your retention, a tamper-evident chain with an independent verifier, in-path PII detection with a redaction reference, a publishable subprocessor list, and an exit that's a SQL query. Then ask which of those they'd want to own, test, and defend in front of an examiner.
The close: "The client we did this for has a large engineering organisation and chose not to. Not because they couldn't — because two quarters of their platform team is expensive, and none of it ships product."
Never answer this by claiming the integration is difficult. An architect knows it isn't, you lose the room, and you've just told them the thing they were about to test is the thing you were bluffing about. The answer is the governance, every time.
"Who else in financial services runs this?" Answer honestly
No named financial-services logo yet — the flagship reference is in regulated healthcare. Being early is the trade: design partners get roadmap influence and preferential terms. Do not invent a client. The entire credibility position is that we publish what we can prove.
"Is it open source? Can we self-host?"
The method — process, skills and patterns — is open source, genuinely free, take it. The engines (OneDroid Synapse, OneDroid Engram) are free to use and hosted or deployed by us; the source stays ours. Enterprise adds grade — SSO, compliance-grade audit and retention, dedicated deployment, advanced policy — it never removes capability from the free tier.
"What does it cost?"
Depends on deployment and scope. Michal will walk you through it. (Then stop talking. Do not improvise a number.)
"How long until we see anything?"
The reference engagement ran two quarters end to end, but the first governed gateway with a live audit trail is a much shorter piece of that. Scope it with Michal rather than promising a date.
"We already have DLP."
DLP was built for files and email. It generally doesn't parse an agent's tool call, and it can't tell you which tool the agent was allowed to reach. This scans in the request path and records the authorisation decision alongside it.
"Won't this slow our developers down?"
The opposite is the usual outcome — what stalls AI adoption in regulated firms is risk review, not tooling. Giving compliance a record is what unblocks the engineers.
08Never say this — the hard bans
These are not style preferences. Each one has already caused a real problem, or would fail a security review.
- "All your data stays inside." False. Inference transits, for everyone. Use the §7 framing.
- Never name the case-study client. Identity is withheld: "a US enterprise in the medical-data industry."
- Never call anything but OneDroid Synapse and OneDroid Engram a product. If a third name is about to come out of your mouth, check first.
- Never quote a price — including "starts around," "roughly," or a range from any older document.
- Never say we make anyone compliant or certified. We produce evidence; their compliance function reaches the conclusion. "Makes you FINRA-compliant" is not a sentence we own.
- Never promise the gateway makes AI safe or vouches for what an agent does. Our own terms say the opposite — we transport, authorize and log; we do not decide or vouch.
- Never say "no third parties" or "we never see your content." Subprocessors are named publicly, including OpenAI for OneDroid Engram embeddings, and the audit-log claim is deliberately hedged. Use the §7 answers verbatim.
- Never sell open-source models as cheaper or good enough. They are an option to measure, not a recommendation. Overselling this is the fastest way to lose a technical room.
- Never cite counts you haven't checked. A count is a claim that rots. The numbers in §6 are dated August 2026; if you're quoting them months later, check first.
- Never assert a specific capability is enforcing today without checking. Some controls in the reference deployment run in audit mode rather than blocking, and one detection gate is proven in a single application rather than platform-wide — both stated openly in the case study. Hard capability questions for an RFP or security questionnaire go to Michal, not to this sheet.
- Don't play compliance lawyer. Ask the question; let their team cite the rule.
If you are ever unsure whether a sentence is true — don't say it, ask. The brand is "if a claim can't be verified, we don't make it." That is worth more than any single deal.
09How to engage — the handoff
- STEP 1
Send the intro. Lead with a failure, not a pitch. Subject lines that work are confessions: "The most useful thing our AI did was fail" · "Our AI invented a compliance field. Then it got caught." · "Our QA record: 6 pass, 3 fail, 5 conditional." Company-specific drafts already exist — ask Michal rather than writing from scratch.
- STEP 2
The hook is the first sentence after the greeting. Personal context goes after it, or in a P.S. Never before.
- STEP 3
Close with the forward, not a meeting. "Happy to send the case study — judge the fit yourself."
- STEP 4
On any yes, tell Michal immediately. He sends the case-study PDF. Never attach it cold.
- STEP 5
Hand over what you know: who they are, what AI they already run, who owns AI risk internally, and any timing pressure — an exam, a client security review, a stalled rollout. That context is worth more than the introduction itself.
Contact: Michal Bacia · michal@onedroid.ai · onedroid.ai
10Glossary — so you can hold the conversation
| Term | Say it like this |
|---|---|
| MCP | The emerging standard for how AI tools connect to systems. Think "USB for AI tools." |
| Agent | An AI that takes actions — reads a ticket, queries a database, sends a message — not just chats. |
| OneDroid Synapse | Our gateway. Everything agents do passes through it, so it's the one place to see and control it. |
| OneDroid Engram | Governed memory for agents — what they're allowed to remember, searchable and audited. |
| Curated context | The firm's own data, scoped and governed, handed to a model for one job — instead of handing over the data wholesale. |
| Upstream | Anything that plugs into the hub — a tool, a system, a data source. Adding one is a configuration decision that gets recorded. |
| Harness | The application an agent runs in — Claude Code, Codex, Cursor, or something the firm built. Interchangeable, because the integration lives in the hub, not in the harness. |
| Dark Factory | The method for building software with AI agents where an independent reviewer must refute every claim before it advances. Open source. |
| Tamper-evident audit trail | A cryptographically chained record. A log file records what a system says it did and anyone with write access can edit it; this lets a third party detect alteration. |
| In-flight detection | Sensitive data is caught as the request happens, not found in a batch scan afterwards. |
| Shadow AI | Employees using AI on personal accounts the firm can't see. The thing we fix. |
Partner enablement, August 2026 · rev 4. Figures dated August 2026 — check before quoting them later. Questions, or anything you're unsure you may say: michal@onedroid.ai.