An AI-agent platform for participants in Michał Połuch’s program

Who the client was and what was getting in the way

Michał Połuch runs an educational program sold as a digital product. Participants were to receive a set of AI agents supporting specific tasks from the program, such as a bonus-idea generator. Until then, these resources were scattered, and someone had to grant access by hand each time.

The first challenge was making the experience cohesive. The agent chat, user accounts, subscriptions, and post-sale support needed to be one application, not a collection of tools connected by links. Participants should be able to sign in once and find everything there.

The second challenge was access control. Every agent query has a cost, so access needed to depend on an active subscription and usage needed a daily limit. Messages explaining that a limit had run out or access was inactive also had to be clear; otherwise, each case would come back as a support ticket.

Third, the journey from purchase to an active account had to require no action from the program owner. Fourth, prompts and models for individual agents had to be changeable without releasing a new application version, and an outage in the external configuration service could not make the platform stop working.

What we built

We built the application in Next.js and based accounts, database, and permissions on Supabase, including row-level security rules so no user could access someone else’s conversations. We added sign-up and login, an account screen with a profile, and a chat interface that supports multiple agents.

Before any request reaches a model, it passes two checks: whether the subscription is active and whether the daily limit has been reached. Both checks happen on the server, so they cannot be bypassed from a browser.

Responses are generated through OpenRouter and streamed, so text appears as it is produced instead of after several seconds of silence. Each agent’s prompt and model are stored in Agenta Cloud, making changes to its behavior a configuration update rather than a new deployment. If that service is unavailable, the platform falls back to the last known configuration instead of refusing to serve requests.

We connected sales through a webhook to Publigo. Purchase events are signed and verified; once the signature is validated, the system creates an account and activates the subscription automatically. Conversation history is saved, so participants can return to an existing thread rather than starting from scratch. Finally, we added an automatic reply to incoming messages outside business hours, sent through Resend, with a frequency limit so no one receives the same message five times.

How it works today

The work took about a week and was divided into four stages: mapping the purchase and access process and designing the data model; building the application and login; integrating models and sales automations; and, finally, stabilization and production deployment.

Now a participant buys the program and has a working account shortly afterward, without contacting support. They sign in, choose an agent, and start a conversation with responses streaming in. Threads are saved. Daily limits control model costs in the background and surface only when someone actually reaches the limit. The program owner can change agent prompts and models through the configuration whenever they want an agent to respond differently.

The outcome

There is one platform instead of a collection of disconnected tools. Access activates automatically after purchase, so support does not bottleneck sales. Subscriptions and daily limits control access to agents and keep model costs in check. Agent configuration is separate from the code, and an outage in the configuration service does not stop the platform.

What we would do differently

The sales webhook turned out to be the most sensitive part. It is the only place where an external system can create an account, so signature verification and protection against duplicate events were mandatory from the first line of code. We implemented them correctly, but tested only at the end against the live purchase flow. Next time, we will set up a way to replay events in a test environment right at the beginning.

We also underestimated the need for a fallback when external agent configuration is unavailable. The first version assumed the service would always be online. One brief outage made it clear that the system should default to the last known configuration, not an error message.