# Build an event signup site for your user

Help a nontechnical organizer get a working registration site. DeepSpace plans to let agents handle the app and infrastructure setup themselves.

Your user is organizing a workshop, a community meetup, or a volunteer day.
They need a page people can open, a way to register, and a list they can
manage. They ask you to build it.

The organizer should be able to explain the event and receive a working
website. Choosing hosting, configuring storage, and creating developer
accounts should be work you can handle for them.

**Product preview, October 11, 2026:** self-serve agent accounts and math
verification are planned. Public account creation currently uses human OAuth.
The event app described here is an example you would build with the SDK,
not a prebuilt registration service or a claim that autonomous signup is live.

## Get the event decisions from the organizer

Find out the date, location, capacity, required registration fields, and who
should have access to the attendee list. Keep the first version focused on
the actual event. If the organizer needs a waitlist or cancellation flow,
include those in the brief.

An RSVP site without payments is a useful autonomous-hosting example. Paid
tickets introduce a payment action, which will require a human under the
planned agent account policy. An event registration form and a hosting
platform signup are also different things: this app collects registrations
while the agent handles the platform setup.

## Build the public page and the organizer's view

Use the frontend to explain the event and collect registrations. Use
persistent records to store them and backend checks to enforce the rules.
The organizer needs a view of registrations that works without editing code.

Keep private attendee information out of the public page. A confirmation
should show the visitor what they need to know without exposing the whole
attendee list. Consult the [permissions guide](/concepts/permissions) when
implementing the organizer's access.

If there is a capacity limit, enforce it on the backend and test simultaneous
submissions. A full event should return an understandable result. Repeated
clicks or network retries should not silently create duplicate registrations.

Start with [building an app](/guides/building-an-app) and
[data storage](/guides/data-storage) for the current SDK workflow.

## Give the human a usable result

Before returning the URL, register as a visitor, confirm that the record
appears for the organizer, and reload both views. Check that an ordinary
visitor cannot access the private list. Try the page on a small screen.

Explain how the organizer views registrations and changes the event details.
Don't promise confirmation emails, calendar sync, or other integrations
unless you actually implemented and verified them.

The intended autonomous flow will let you create the account, build the app,
and deploy it without a human opening accounts on infrastructure services.
That leaves the organizer with the event decisions and a link they can share.

## Keep the site useful after the first session

The planned permanent agent account means the site won't disappear when your
container ends, and there will be no mandatory human claim deadline. You can
return for authorized changes, such as opening another workshop date, while
retaining the existing app identity and appropriate data.

Hosting will remain subject to resource limits and moderation. Agree with the
organizer on what should remain available after the event. Permanence gives
you continuity; it doesn't require retaining attendee data indefinitely.

See [completing your user's request without platform signups](/agents/complete-your-users-request-without-platform-signups)
for the broader premise and [permanent websites](/agents/permanent-websites-for-ai-agents)
for the proposed account behavior.