Inspiration

Space Zero was inspired by a simple question I always asked myself. What if AI travel agents could do more than the usually booking of trips? It was a definitely intriguing concept to explore. Most travel tools can help you find flights, compare prices, and build an itinerary. But when a journey is disrupted, the traveler still has to take over. They have to understand what happened, search for alternatives, compare new prices, decide how much they are willing to spend, and make another booking. That is where the idea for Space Zero came from. And I just decided to build it further.

What it does

Space Zero is an autonomous travel operator that can help manage a user's journey.

Plan → Select → Fund → Authorize → Monitor → Detect → Recover → Resolve or Escalate

The traveler defines:

Their trip requirements Budget and preferences Funding Recovery authority

Space Zero then coordinates the available tools to operate within those boundaries.

The system can:

• Create and persist trips • Search flight options • Select travel options • Track trip state • Monitor for disruptions • Evaluate recovery alternatives • Check funding • Enforce a recovery allowance • Execute permitted actions through controlled tools • Escalate when an action exceeds authority

How we built it

Space Zero was built as a Next.js and TypeScript application with the Strands Agents SDK as the agent orchestration layer.

The architecture separates AI reasoning from consequential execution.

The agent is responsible for understanding the situation, coordinating tools, and selecting an appropriate recovery strategy.

Space Zero integrates with:

• Strands Agents SDK for agent orchestration and tool use • Gemini as the currently working model provider • Supabase for persistent trip and execution state • Duffel for flight search and test-mode booking flows • FlightAware for flight monitoring integration • Airwallex for payment integration • Vercel for deployment

External providers can fail or be unavailable, so the application was designed to fail honestly rather than fabricate success.

Challenges we ran into

• Building with real external systems

Real APIs do not behave like demo APIs.

Different providers had different sandbox capabilities, credentials, account requirements, and failure modes. We encountered provider configuration limitations and model-access restrictions during development.

• Model provider availability

We initially planned to run the agent through Amazon Bedrock. The application architecture and Strands integration were wired for Bedrock, but account-level model invocation restrictions prevented a live model call during development.

Rather than stopping the project or pretending the integration worked, we added a provider abstraction and connected Gemini as a working model provider.

The important architectural lesson was that the agent layer should not be tightly coupled to a single model provider.

• Payment integration

Payment was another important challenge.

A payment API being authenticated does not automatically mean a sandbox merchant account can complete every payment flow. We encountered sandbox merchant configuration limitations that prevented the intended payment flow from reaching a successful terminal state.

We kept the safety gates intact.

A failed or pending payment cannot produce RESOLVED.

This was more important than forcing the demo to show a fake successful payment.

Accomplishments that we're proud of

What we learned

The biggest lesson from Space Zero was that autonomy is not the same as unrestricted action.

An agent becomes useful when it can act without requiring constant instructions.

But an agent becomes trustworthy when it has clear boundaries around what it is allowed to do.

We learned how to:

• Build tool using agents with Strands • Design controlled execution paths • Integrate multiple external APIs • Handle provider failures honestly • Persist long-running agent workflows • Build explicit state transitions • Test authority and funding boundaries

What's next for Space Zero

Space Zero is currently a hackathon prototype, but the architecture points toward a larger vision.

Future work will include:

• More reliable real time monitoring • Broader travel provider coverage • Production ready payment flows • Multi step journey recovery

Built With

Share this project:

Updates

Submission history