-
-
home page
-
the agent handling overlapping events
-
Asks for approval-human in the loop
-
overview of all the events
-
Helps organize tasks
-
Calender View for better management
-
easily find venues on a date
Inspiration
The three of us are all in college clubs, and between us we've run a lot of events — workshops, guest talks, hackathon prep nights, the usual. And every single time it's the same grind: is a room free, does it have a projector, what's this going to cost, does someone need to sign off on it, who's doing what by when. None of that is actually hard. It's just annoying and repetitive and it eats the time that should go into making the event good.
We'd joked for a while that someone should just automate all of it. When the Agents for Humans hackathon came around and required the Strands Agents SDK, that was our excuse to stop joking and actually build it.
What it does
You type one sentence, something like:
"Organize a web development workshop for 55 students on September 11 from 10 AM to 1 PM. We need computers and a projector."
And OrbitOne goes and does the actual work:
- Finds a room that fits the capacity, time, and equipment
- Tells you why a room doesn't work instead of just rejecting it silently
- Creates the prep tasks (book the room, confirm the speaker, order snacks, etc.)
- Estimates costs and checks them against the org's real budget rules
- Handles the low-stakes stuff on its own, but stops and asks a person before spending over the approval limit
- Keeps a log of what it did and why
We didn't want to build something that replaces the person running the event. We wanted it to take the busywork off their plate so they only have to think about the decisions that actually need a human.
How we built it
We split it three ways: one of us on the Strands agent itself, one on the FastAPI backend and database, one on the React frontend. The agent runs on Strands, with the model swappable between Groq, Gemini, Anthropic, Ollama, or Bedrock, so we weren't stuck if one provider gave us trouble.
The backend is FastAPI and SQLite, with real endpoints for rooms, bookings, tasks, budgets, and approvals. The agent isn't allowed to make any of that up. Every tool call goes through the actual database, scoped to one organization at a time, so it can't invent a room that doesn't exist or see another club's data.
The frontend just polls the backend so you can actually watch the agent work instead of getting a wall of text back at the end.
Challenges we ran into
Most of the pain wasn't the AI part, honestly. It was three people's code meeting for the first time.
The backend worked fine when we hit it directly through Swagger, then broke as soon as the frontend was wired up, because the database hadn't been seeded yet. It was returning correct, empty responses, which looked exactly like broken responses from the frontend side. Good reminder that "the API answers correctly" and "the app works" are not the same thing.
We also lost a chunk of time to a bug where the agent's .env file just wasn't loading, because load_dotenv() had no path and the backend starts the agent from a different working directory than expected. So it silently fell back to Bedrock, which we hadn't gotten approved for, and threw a pretty cryptic AWS error while our actual config sat there unused the whole time.
And at one point SQLite started complaining about a missing column that was very clearly in our model. Turned out the database file had been created before we added organization scoping to locations, so the code and the actual file had drifted apart. Fixed it, but it was a good lesson in why changing a model isn't the same as migrating a database.
Picking a model provider took some trial and error too. We started with Gemini, but its free tier has a daily request limit that we kept slamming into mid-testing. Ollama was appealing since it's free and local, but it was too slow for what the agent needs to do, which is call several tools in a row for a single request. We also tried Bedrock, but that needs model access approved on your AWS account first, and we hit a wall with a ValidationException: Operation not allowed error before that approval came through. Groq ended up being the one that just worked: free, fast enough for the full tool-calling loop, and no daily cap slowing us down mid-demo.
Accomplishments we're proud of
It actually works end to end. You type a request, the agent does real backend work, and there's a real approval step gating anything that shouldn't be fully automatic. Nothing about it is faked for the demo.
What we learned
Supporting multiple model providers was worth the setup pain, because when one gave us grief we could just swap it out instead of being stuck. And honestly, the hardest bugs weren't inside anyone's individual code, they were at the seams where our three pieces connected. Figuring out exactly where the agent should be autonomous and where it needs to stop and ask a human ended up being the actual design problem, not something we bolted on afterward.
What's next
Real integrations are the obvious next step, calendar syncing, email or Slack notifications, and support for more than one organization at a time. We'd also like to add participant-count and notice-period rules, since right now budget threshold is the only policy actually enforced.
Log in or sign up for Devpost to join the conversation.