A developer opens an AI coding environment and gives it a straightforward instruction:
Add privacy-preserving KYC before users enter this part of the product.
The instruction is simple. The work behind it is not.
The developer still needs to understand the provider, create an account, select the appropriate capabilities, configure a verification policy, protect credentials, connect the SDK or API to the application flow, and test successful, failed, and interrupted verification.
Those steps are often scattered across documentation, dashboards, support conversations, and source code. An AI agent can summarize each page, but that does not complete an integration. The harder problem is turning a fragmented checklist into one controlled workflow.
That is the product problem behind zkMe’s Agentic Self-Service initiative. The goal is to give developers an agent-guided path from initial discovery to a working zkKYC flow inside their own product—while keeping sensitive information and consequential compliance decisions under merchant control.
What the workflow looks like
The Agentic Self-Service workflow zkMe is building follows six connected stages.
1. Discover and understand zkMe
The journey begins before a merchant account exists. An agent must first understand what zkMe does, which capabilities are relevant, what prerequisites apply, and where the authoritative integration instructions live.
Machine-readable resources, a focused Quickstart, and consistent terminology help the agent build that map. Instead of sending the developer through an entire documentation portal, the agent can retrieve the relevant path, explain it in the context of the developer’s product, and identify the decisions that must be made next.
2. Register the merchant account
The agent gathers the non-sensitive information required for registration and presents a summary before anything is submitted. Actions involving authentication remain outside the conversation: the merchant sets a password on a secure page and confirms when the step is complete.
The distinction matters. Agentic onboarding should remove repetitive coordination, not encourage developers to expose credentials in a chat window.
3. Select products and configure access
The agent explains the available products and permissions, but the merchant makes the selection. Once access is configured, the workflow guides the merchant through domain allowlisting and credential setup.
Raw keys are never treated as conversational inputs. The agent explains where a credential should be obtained, how it should be stored, how the application should read it, and how it can later be rotated or revoked. It then continues from confirmed system state rather than assuming the step succeeded.
4. Configure the KYC Program
There is no universal KYC configuration for every product. The appropriate Program depends on the merchant’s users, markets, risk requirements, and the point at which verification should occur.
The agent therefore asks what the merchant needs to verify, explains the available settings and their consequences, and may recommend a configuration. Before the Program is created, the merchant reviews and approves the complete proposal. Recommendation and authorization remain separate actions.
5. Integrate zkMe into the merchant’s product
This is where the workflow moves beyond documentation assistance. With access to the project the developer has chosen to share, the agent identifies the technology stack, authentication model, routes, and business state affected by KYC.
It then prepares the SDK or API integration in the actual product journey. Callback and webhook addresses are derived from the merchant’s real environment rather than copied from a generic example. The integration is designed around what the application should do after a successful, declined, pending, cancelled, or unavailable result.
6. Run and validate a sandbox verification
Configuration is not completion. The merchant runs a real sandbox KYC journey inside the product, and the application retrieves an authoritative result.
The workflow verifies that the correct business action follows: access is unlocked when the required condition is met, blocked when it is not, and handled explicitly when the process is incomplete. Only then has the integration moved from a collection of settings to a working product capability.
The real product is the connection between stages
Each of these tasks can be documented separately. The strategic value comes from connecting them.
A useful agentic workflow knows which steps have already succeeded, which decisions belong to the merchant, which actions require a secure interface, and which system response is authoritative. If a process is interrupted, the developer should be able to resume from the last confirmed state rather than restart from the beginning.
This makes Agentic Self-Service different from placing a general-purpose chatbot in front of documentation. A chatbot produces answers. A workflow coordinates decisions, tools, state, and validation toward a defined outcome.
Identity onboarding makes this distinction especially important. The process touches regulated choices, access permissions, application secrets, verification policies, and user-facing product logic. A convincing response from an AI model cannot be accepted as proof that any of those states changed correctly.
Five principles for an agent-native identity workflow
The zkMe workflow is shaped by five principles that make agent-assisted integration useful without making it uncontrolled.
1. Make discovery machine-readable
Agents need a reliable map of the product: what it does, when to use it, what the boundaries are, and where detailed instructions can be found. Resources such as llms.txt, structured Quickstarts, and stable documentation paths make discovery part of the product interface.
This matters commercially as well as technically. When developers begin a project inside an AI coding environment, infrastructure that agents can accurately understand is easier to evaluate and integrate.
2. Advance only on authoritative state
“Submitted” is not the same as “active,” and a completed browser action is not necessarily a confirmed configuration. The workflow should read the relevant product state after an action and advance only when the expected result is present.
This approach also makes recovery clearer. Instead of improvising after a failure, the agent can identify the incomplete stage, explain what remains, and continue without duplicating successful actions.
3. Keep sensitive actions outside the conversation
Passwords, API keys, private keys, verification links, and identity documents should not be pasted into an agent conversation. The agent can explain the action, direct the user to a secure surface, specify an appropriate storage location, and confirm completion without taking custody of the underlying secret.
The objective is not merely to automate more steps. It is to design an integration path with a smaller and more explicit exposure surface.
4. Separate recommendations from decisions
An agent can help a merchant understand products, permissions, and KYC settings. It should not silently convert a recommendation into consent.
Before a consequential action, the workflow presents the proposed choice and its effect. The merchant can approve it or revise it. This preserves human authority while still allowing the agent to do the analytical and operational work surrounding the decision.
5. Finish inside the merchant’s product
An onboarding journey is not complete because a dashboard has been configured. It is complete when the merchant’s application can launch verification, receive a trusted result, and apply the correct business logic.
That definition of completion keeps Agentic Self-Service focused on developer outcomes rather than agent activity. The measure of progress is not how much the agent said or how many pages it opened; it is whether the intended integration works.
Why this matters for zkMe
Agentic Self-Service creates a new route into zkMe’s infrastructure. Machine-readable discovery helps zkMe meet developers where product decisions increasingly begin. A connected workflow then reduces the distance between understanding zkMe and experiencing a working integration.
It also turns integration expertise into a repeatable product capability. Guidance that would otherwise be reconstructed in separate support conversations can be expressed as stages, decision points, safety boundaries, and validation rules. That can make the onboarding experience more consistent while allowing technical teams to focus on the exceptions that genuinely require human expertise.
The workflow becomes more valuable as the product grows. Discovery, secure configuration, permissioning, state verification, code integration, and recovery are not limited to one screen or one integration method. They form a reusable operating layer for supported identity and compliance services.
Most importantly, the difficulty of building this well is also part of its defensibility. The challenge is not generating plausible instructions. It is coordinating merchant intent, product state, credentials, policy configuration, application code, and verification outcomes without blurring the boundary between assistance and authority.
From prompt to proof
The promise of AI-assisted development is not that every action becomes autonomous. It is that a developer can express an outcome and receive coordinated help completing the work required to reach it.
For zkMe, that outcome is concrete: a merchant moves from asking for privacy-preserving KYC to running and validating zkKYC inside its own application. The agent handles discovery, explanation, orchestration, code changes, status checks, and recovery. The merchant controls product selection, compliance configuration, sensitive actions, and final approval. zkMe provides the authoritative state on which the workflow depends.
That division of responsibility is what turns a prompt into more than a conversation. It turns it into a controlled path to a verified integration.