Governed Booking Agent

• 

Inspiration

Independent service providers often lose booking opportunities for a simple reason: they cannot provide a service and manage every digital conversation at the same time.

When someone is working with a client, driving, resting, or away from their phone, a new inquiry may sit unanswered. The usual solution is to add a chatbot, but a chatbot that responds quickly without respecting the provider’s boundaries can create a different problem: it may invent availability, expose sensitive information, quote an unauthorized price, or make a commitment the provider never approved.

We built Goldenboy around a different question:

Can an AI agent complete a booking workflow autonomously while remaining inside explicit, testable boundaries?

What it does

Goldenboy is a governed booking agent for independent service providers.

A synthetic customer inquiry triggers a multi-step workflow. The agent interprets the request, checks the available operational context, produces an appropriate response, validates that response against locked policies, and records the resulting action and state transition.

The demo applies four categories of non-negotiable policy:

• Sensitive location information
• Prices and commercial commitments
• Clinical or professional advice
• Whether the agent has been authorized to operate autonomously

If a response violates a policy, Goldenboy does not send it. The system performs one constrained retry. If the second attempt still fails, the interaction moves to needs_review for human intervention.

The successful path and every failure path are written to an audit record. This makes it possible to see what the agent attempted, which policies were evaluated, why an action passed or failed, and whether a person needs to take over.

The hackathon demo uses synthetic information and a controlled messaging interface. It does not contain private customer conversations or production data.

How we built it

Goldenboy uses Gemini with Google’s Agent Development Kit to coordinate the workflow.

The application is organized into separate components:

1. An event handler receives a booking inquiry.
2. Firestore stores the request, workflow state, attempts, and audit events.
3. The agent receives only the context and capabilities permitted for that interaction.
4. Gemini produces a proposed response or booking action.
5. A deterministic policy validator evaluates the proposal.
6. A passing action is committed to the demo outbox and booking state.
7. A failed action receives one constrained retry before being escalated to needs_review.

The backend is designed for Cloud Run, with Firestore providing persistent state across requests. A minimal interface shows the inquiry, the agent’s decision, policy results, state transitions, and audit trail.

We also created eight scenario-based tests covering successful execution, restricted information, unauthorized commitments, retry behavior, escalation, and duplicate-event handling.

Challenges we faced

The hardest challenge was separating language generation from operational authority.

Prompt instructions alone were not enough. We needed deterministic controls outside the model so that a fluent response could not bypass a business rule. This led us to treat Gemini as the reasoning and drafting component while keeping authorization, validation, state transitions, and final execution under explicit system control.

Persistent state was another challenge. A retry must not create a second booking, overwrite the first attempt, or forget why the previous response failed. We designed each attempt as a separate audit event and used idempotency controls to prevent duplicate actions.

We also had to resist unnecessary scope. Live telecommunications, payments, private training data, and production integrations would have made the demo larger without making its central idea clearer. We kept the project focused on one complete, observable workflow.

What we learned

We learned that safe autonomy is not the absence of human control. It is the ability to define exactly when the system may act, when it must stop, and what evidence it must preserve.

We also learned that an agent can provide value even when its correct action is to refuse, pause, or escalate. Completing a workflow does not always mean sending a message. Sometimes completion means preventing an unsafe commitment and delivering a structured case to a human reviewer.

Most importantly, we learned that governance works best when it is part of the architecture rather than a policy document added after development.

What’s next

The next step is to validate the workflow with independent service providers using authorized, privacy-preserving data.

Future versions may add provider-controlled personalization, calendar integrations, approved communication channels, multilingual behavior, and production monitoring. Each capability will remain locked until its safety, consent, and operational requirements have been satisfied.

Goldenboy’s long-term goal is straightforward: help independent professionals respond more consistently without asking them to surrender their identity, judgment, or control.

Built With

• firestone
• gemini
• geminiapi
• google-cloud
• governedai
• phyton
• policyengine