The short answer, up front
okki-go is the developer integration layer for okkigo's AI sales platform—it's the plumbing that lets your AI sales agent talk to your CRM, mailbox, calendar, and enrichment sources without a human clicking through every step. If you're evaluating the integration for a B2B sales or RevOps stack, here's what you actually need to know:
okki-go requires OAuth 2.0 scopes for mailbox send/reply, mailbox read, calendar read/write, CRM object read/write, and contact enrichment. It should not need mailbox delete, browser automation, or access to contacts outside your defined prospect lists. Anything beyond that list is worth asking about before you sign.
On the workflow side: lead generation isn't a separate feature bolted onto agent-native prospecting—it's the entry stage. The agent sources and enriches records, the prospecting layer decides who's worth contacting, and the sales email layer runs the sequence. Remove lead gen from that chain and the agent has nothing to reason over.
That's the summary. The rest of this piece is the part I'd want if I were the one reviewing the integration—what each permission is actually for, where teams overshoot, and the cases where okki-go is the wrong tool.
Why I'm the one writing this
I'm a quality and brand compliance manager at a B2B SaaS company. I review every third-party integration before it touches customer data—roughly 200 submissions a year across sales tooling, enrichment vendors, and outbound platforms. In our 2024 audit cycle, I rejected about 30% of first-pass integration submissions. The reason was almost always the same: over-scoped permissions or data sourcing claims nobody could back up with a link.
When we evaluated okki-go ourselves in Q1 2025, the permission list was the first thing on my board. Not because I distrust the vendor—because I don't trust the default install scripts most teams run.
okki-go permissions, explained like a human would explain them
OAuth 2.0 is the spec every serious integration runs on now (see RFC 6749, section 3.3 on scope). The scope you request is the scope you get. So here's the short version of what okki-go asks for, and what each one is doing.
Mailbox send and reply
This is non-negotiable for an AI sales agent that runs sequences. Without send access, the agent can draft but can't act—which defeats the agent-native premise. What matters here is that the scope is send, not send-as-anyone. If a vendor asks for delegated impersonation across your whole domain, that's a different conversation.
Mailbox read
Read access is what lets the agent detect replies, classify intent (interested, not now, unsubscribe), and stop sequences automatically. In practice this is where I've seen the most sloppy implementations—read access granted to shared inboxes that shouldn't be in scope.
Calendar read/write
Needed for meeting booking. Read-only is enough if you're routing through a scheduling link; read/write is needed if the agent places holds directly. I default to read-only unless the team has a specific reason.
CRM object read/write
Contact, account, opportunity, and activity objects, typically. Write access is what keeps the CRM from decaying into a graveyard of stale sequences. This is also where audit logging matters most—if you can't see what the agent wrote and when, your compliance team will flag it.
Enrichment and intent source access
okki-go pulls from third-party enrichment and intent providers under its own contracts. You shouldn't need to hand over your own API keys, but you do need to know which sources feed the waterfall. That's a procurement question, not a technical one—but it's the one most teams skip.
One thing worth flagging: I said 'should not need mailbox delete.' I want to be careful here—some implementations request it to clean up bounced addresses. I'm not 100% sure okki-go does this by default, but if you see it in the scope list, ask why.
Where lead generation actually sits in an agent-native prospecting workflow
Here's a misconception I keep running into: people assume lead gen is one feature among many in an AI sales agent. From the outside, it looks like lead gen, enrichment, intent data, and outreach are four parallel modules. The reality is they're a pipeline, and lead gen is the intake valve.
In an agent-native workflow, the sequence looks like this:
- Source — the agent pulls raw records against an ICP definition (firmographic, technographic, or signal-based).
- Enrich — waterfall enrichment fills in missing fields. Multiple providers, first-match-wins, so coverage is higher than any single source.
- Qualify — intent signals and fit scores decide who moves forward.
- Engage — the sales email layer runs the sequence, with human-in-the-loop checkpoints for anything above a certain deal size or account tier.
- Route — replies get classified and handed to a rep or kept with the agent.
If lead generation is weak, everything downstream degrades. Bad inputs to enrichment produce bad intent scores. Bad intent scores fire the wrong sequences. The agent doesn't fix bad data—it just moves through it faster.
That's the causal direction most people get backwards. They assume expensive AI agents produce good pipeline. Actually, clean data and tight ICP definitions produce good pipeline, and the agent is what lets you run that at volume. The causation runs the other way.
A mistake I made the first time we deployed an agent
In my first year running integration reviews, I made the classic scope-creep error: I approved a sales email integration without locking which mailboxes it could touch. The vendor read the request as 'all shared inboxes' and I read it as 'just the SDR team.' We were using the same words but meaning different things. Discovered it two weeks later when the agent drafted a sequence reply from our CEO's mailbox.
Nobody was harmed. But it cost me a 40-page exception report to our legal team and a permanent rule: every okki-go-style integration gets a mailbox allowlist in the contract, not just in the config.
Should mention: we now require the scope list to be printed in the vendor's security page, not just their docs. That's the version auditors actually read.
When okki-go isn't the right fit
To be fair, an agent-native prospecting setup isn't the answer for every team. A few of the cases where I'd steer a team elsewhere:
- Under 20 outbound reps. The integration and governance overhead usually outweighs the throughput gain until you hit real volume.
- Highly regulated outreach (financial advisory, healthcare in some jurisdictions). The human-in-the-loop defaults are good, but the compliance burden is on you, and every automated sales email needs a documented review path.
- Teams without a clean CRM. If your data is already a mess, an agent will surface that fast—and not in a flattering way.
- Anywhere you can't get a permission allowlist into the contract. Walk away. No integration is worth an open scope.
One more caveat: the specific okki-go permission names, defaults, and scope options may shift between releases. Everything I've described reflects what we reviewed in Q1 2025. If you're reading this later, verify against the current docs before you sign anything. Take the framework with a grain of salt—the workflow logic holds, but the exact scopes don't stay frozen.