The Inspiration: A Problem That Doesn't End When Support Says It's Solved
Imagine cancelling a subscription, only to discover you've been charged again.
You contact support. You explain what happened. They apologize, promise to fix it, and close your ticket.
A week later, nothing has changed.
Your subscription is still active. Your money is still gone. And when you contact support again, you're asked to explain everything from the beginning.
The company says your case is resolved. But you're still living with the problem.
That contradiction is what made me question how customer support works.
We've built systems that can answer questions in seconds, generate convincing apologies, automate workflows, and close thousands of tickets.
But I kept coming back to one question:
What if the AI could actually prove that the customer's problem was solved?
Not just say it submitted a request.
Not just promise someone would follow up.
Not just mark a ticket as closed.
Actually verify that the intended outcome happened.
That question became Orylo.
A system built around one simple belief:
Support shouldn't end when the conversation ends. It should end when the problem is genuinely resolved.
Meet Orylo: support should finish the job
Orylo is a working prototype of Verified Resolution Infrastructure. Its guiding principle is Detect → Decide → Execute → Verify.
The first scenario is Failed Cancellation & Billing Recovery for Northfield Digital, a fictional subscription company. It focuses on a customer who previously requested cancellation but was charged again.
Orylo does not simply write an apology. The local system checks the synthetic account and case state, evaluates a versioned policy, requires permitted consent, invokes a constrained action, and reads the stored result back.
If the cancellation is corrected but the disputed charge is still being reviewed, it says exactly that:
Cancellation: verified. Billing review: pending. Refund: not issued.
That is an intentionally partial outcome. Pretending everything is resolved would be easier—and wrong.
The customer journey
Detect the failed promise. The case preserves previous attempts, synthetic account records and the customer's desired outcome. A returning customer should not have to begin from zero.
Decide with authority. Approved policy versions, identity scope and customer consent determine what can happen next. Unsupported requests are declined or escalated instead of being guessed through.
Execute a real permitted change in the simulator. The Action Gateway applies an authorized cancellation correction to a synthetic subscription. Repeated requests are idempotent, and stale state can block unsafe actions.
Verify the result. The backend reads the changed state back and records outcome evidence. The database prevents a case being marked verified-resolved without supporting evidence.
Keep the unfinished work alive. A separate billing review can remain pending, and escalation preserves the case context for the next responsible person.
The moment that makes Orylo different
The most important moment is not an AI-generated answer. It is when an attempted resolution has to prove itself.
A system can say an action succeeded. Orylo checks whether the intended state really changed. If it has not, it must not show a verified-completion state.
This is also why an action receipt, a human approval, and a customer outcome are different objects in the product. They cannot be collapsed into one optimistic status label.
How I built it
The prototype is a modular Next.js 16 + TypeScript application with PostgreSQL 16 and Drizzle ORM, Better Auth, Zod validation, customer and operator experiences, and an administration workspace.
The core implementation includes:
14-state resolution model: explicit transitions for investigation, authorization, action, verification, escalation and reopening. Governed policies: versioned documents and approval rules rather than arbitrary prompt-based authority. Action Gateway: permission checks, customer consent, idempotency and safe handling of stale or failed operations. Outcome Ledger: append-only, hash-chained records and read-back verification evidence. Three synthetic workflows: failed cancellation and billing, missed appointments, and warranty claim readiness. Human handoff: preserved case and prior-attempt context. Testable eGain-facing API: five prepared HTTP action endpoints for the future live sponsor-platform workflow.
Everything currently runs against fictional customers and a simulated service provider. No real financial transaction or refund occurs.
Why eGain matters
The competition architecture assigns eGain the customer-facing AI agent: source-grounded knowledge, intents, pre-chat information, guided workflows and human escalation. Orylo supplies the narrowly controlled backend actions and outcome verification.
A complete eGain commissioning package is prepared in the repository, including 12 synthetic policy documents, intent definitions, a failed-cancellation guided flow, two escalation options, an OpenAPI action contract and published-agent test scripts.
Current integration status: That package has not yet been configured or tested in an actual eGain tenant. The API is tested locally, but there is no verified published eGain agent or live eGain-to-Orylo action call yet. The final demo must show the real sponsor platform, not a stand-in interface.
The hard engineering problems
- A staff member could forge a customer's consent
An independent static review uncovered a serious authorization flaw: a staff member could issue a case portal link to themselves and potentially act as the customer.
The repair: Operator-issued links were restricted to read-only access, and customer mutation paths enforce authorization separately. A regression test was added.
This was an actual security finding and repair, not a feature planned for later.
- Duplicate actions could change an account twice
Retries are unavoidable, especially if a request times out after the operation has already taken effect.
The approach: Action identity and persisted state are used to protect against duplicate execution. Tests include concurrent confirmations and timeout-after-apply replay.
- A successful API response might still be a failed outcome
The application distinguishes the execution of an operation from verification of the customer objective.
The approach: Read the affected state back and require persisted verification evidence before granting a verified-resolved status. Database safeguards reject unsupported resolution claims.
- AI and policy can disagree
A fluent explanation cannot authorize an operation.
The approach: The application maintains an approved policy pack, validates typed policy rules and blocks operations that do not meet the deterministic authorization conditions. A planned eGain agent must answer from the authorized source material rather than invent its own rules.
- A beautiful interface can conceal a broken workflow
A dashboard can be persuasive while the actual operation behind its button does nothing.
The approach: Test customer-to-operator-to-customer flows using a real PostgreSQL database and browser, and report any incomplete commissioning honestly.
What I verified—and what remains
The implementation's recorded local evidence reports:
88/88 unit, database integration and security regression tests passing. 41/41 Chromium browser tests passing. Clean author-reported local typecheck, lint and production build. Tested concurrency, authorization boundaries, hash-chain verification and database refusal of fabricated resolutions.
These are local test results, not proof of production deployment. The GitHub Actions workflow associated with commit 86c0d20 failed at formatting, preventing its later CI steps from running. The project has not been deployed or connected to eGain. Remaining security and operational limitations are documented in the repository.
What I learned
Trust is a state transition, not a tone of voice. A reassuring agent is not trustworthy if its claimed outcome disagrees with the underlying record.
Human approval must be enforced in code. A prompt telling AI to ask permission is not an authorization boundary.
Failed attempts belong in the product. Reopening, retries, stale records and escalations are normal customer experiences—not edge cases to hide.
The hardest issues appear in negative tests. The consent-forgery finding reinforced why adversarial review matters even when the happy path works.
A better interface shows uncertainty clearly. "Pending verification" may be less exciting than "Success," but it is much more useful when someone's account or money is involved.
Why this could become a company
Orylo's long-term hypothesis is that subscription businesses, ISPs, and other service operators will pay to reduce repeated customer work and obtain verifiable resolution records.
The architecture is intended to evolve beyond a single chatbot into a customer workspace, operator command center and controlled resolution infrastructure. That opportunity still needs genuine customer discovery, licensing validation and paid pilots. No customers, revenue, cost savings or production integrations are claimed today.
Try it / inspect the work
Source: https://github.com/VictorCyberDev/orylo
Implementation branch: claude/beautiful-ptolemy-87we05
Live agent and video: Not yet available. These will be added only after the eGain agent is genuinely published and independently tested.
All customer records and policy scenarios are synthetic. Orylo was developed during this hackathon period. The working name is provisional and has not been cleared for commercial trademark use.
The ticket being closed should never be the end of the story.
The customer's problem being solved should be.
Built With
- better-auth
- drizzle
- next.js
- playwright
- postgresql
- react
- typescript
- vitest
- zod
