Inspiration

We started with a simple problem: building teams of AI agents is still way too technical. Most tools make you think about prompts, models, routing and workflows before you can even focus on the actual problem.

We wanted to flip that. In QuestMaster, you start with a goal, or a “quest”, and the platform analyzes what work is actually needed, what capabilities are available, and where an agent would genuinely add value.

The fantasy theme came naturally from that idea. Different characters have different skills, tools and responsibilities, and sometimes the best solution is not “magic” at all.

That became our main principle:

The best agent platform knows when not to use an agent.

What it does

QuestMaster is a control layer for reusable AI teams.

Organizations first equip the platform with the data sources, APIs, deterministic functions and AI capabilities their teams are allowed to use. QuestMaster can then analyze a business goal, break it into the work that is actually required, and assemble a team around those available capabilities.

Each agent can have a role, skills, tools, permissions, instructions, guardrails and a budget, but not every step needs an agent or an AI call.

QuestMaster can handle work in different ways:

NO ACTION when nothing actually needs to happen
CODE for deterministic tasks like calculations, filtering or scoring
TOOL for APIs and external data
AGENT when interpretation, judgment or coordination adds value
LLM only when the agent actually needs reasoning or language synthesis

So the agents define who is responsible for the work, while QuestMaster decides how that work should actually be done.

If a goal requires a capability that has not been installed, QuestMaster should not pretend it can execute it. It can identify what would be needed and return that the team still needs setup.

For HackTX, we built a fully configured Toyota mobility and financial decision capability pack. It combines Toyota customer, vehicle, contract and usage context with Capital One Nessie financial data and deterministic financial and decision functions.

The same capability pack can then be used for different goals, such as evaluating a customer's next mobility decision or identifying strong candidates for a new vehicle loan.

How we built it

We split the project between us so we could work in parallel.

Petr focused on the frontend, UX and the fantasy party interface. Eliška focused on the backend, execution logic, integrations and deployment.

The frontend and backend communicate through a REST API, which let us develop both sides independently.

For the backend, we intentionally avoided building a large autonomous agent loop. Instead, QuestMaster first analyzes the job and routes individual pieces of work through deterministic code, approved tools or LLMs depending on what they actually require.

We integrated Capital One Nessie to provide financial context for the Toyota use case while keeping raw financial data separated from downstream AI reasoning. We also use Meta AI for planning and language reasoning, Tiger Data for persistence and observability, and Vultr for deployment on our public .tech domain.

Challenges we ran into

The biggest challenge was scope.

There are many things a general agent platform could eventually support, but a platform cannot truthfully execute a business workflow unless it has access to the right data, APIs and functions.

That led us to separate the generic orchestration layer from domain-specific capability packs. Instead of pretending QuestMaster can perform every possible job, we focused on making one complete Toyota capability pack work while allowing the platform to identify when another use case still needs additional setup.

Another challenge was deciding where AI is actually useful. It is easy to turn every step into another model call, but that quickly becomes slower, more expensive and less predictable.

We also had to keep the interface simple enough for a non-technical user while still exposing useful concepts such as permissions, functions, connections, costs and execution choices.

Accomplishments that we're proud of

We are proud that QuestMaster has a clear architecture rather than being another chatbot with multiple agent names on top of it.

The fantasy party metaphor makes specialized responsibilities easy to understand, while the execution layer gives the platform a practical reason to exist beyond simply creating more agents.

A single quest can include deterministic calculations, external APIs and AI reasoning without treating all of them as the same thing.

We are also proud of the transparency of the execution path. The activity log makes it possible to see which capabilities were used, which permissions were checked, when external tools such as Capital One Nessie were called, and when QuestMaster decided that an LLM was actually necessary.

What we learned

The biggest thing we learned is that multi-agent does not have to mean multiple LLMs constantly talking to each other.

It is more useful to separate:

who is responsible for the work

from

how that work should be executed.

We also learned that a general agent platform does not need to pretend that every possible capability already exists. A reusable orchestration layer can be general while the actual data, APIs and functions remain specific to each organization.

That idea made the backend simpler, gave us a clear way to reduce cost and unnecessary AI calls, and made the platform's limitations much more explicit.

What's next for QuestMaster

The next step is expanding the capability-pack model beyond the Toyota reference implementation.

That means adding more reusable connections and deterministic functions, making it easier for organizations to provide their own data and APIs, and improving how QuestMaster asks follow-up questions when a goal is underspecified.

We also want to make team configuration more expressive while keeping execution grounded in capabilities that actually exist.

The long-term goal is not to create the largest possible number of agents.

It is to make it easy to assemble the smallest useful team for a real business responsibility — and know when an agent is not needed at all.

Sponsor Tracks

NMC2 — Build the Platform Behind the Agent
QuestMaster directly addresses the platform layer behind AI agents. Instead of requiring users to manually configure prompts, models, tools and workflows, QuestMaster starts from a business responsibility, analyzes what work is required, assembles the appropriate team, and manages capabilities, permissions, budgets and execution routing. The same platform layer can be reused across different capability packs and business goals.

Capital One — Best Use of Nessie
For our Toyota financial decision capability pack, Capital One Nessie provides the financial context that makes recommendations genuinely personalized. QuestMaster derives signals such as cash flow, reserves, affordability and financial stress from Nessie data and uses them alongside vehicle and contract information. Raw financial transactions remain isolated from downstream LLM reasoning, while the derived financial context can materially change customer rankings and recommendations.

Toyota Financial Services — “What’s Your Next Move?”
Our Toyota capability pack helps Toyota Financial Services determine not only what the next mobility decision should be for an individual customer, but also which customers need attention in the first place. QuestMaster combines vehicle, contract, usage and financial context to identify relevant customers, compare realistic options and explain the trade-offs behind each recommendation.

For the customer, that means a next step that better reflects both their mobility needs and what they can realistically afford. For Toyota Financial Services, it means a reusable way to prioritize outreach, identify stronger financing opportunities, and avoid treating every customer with the same generic offer.

Because the same Toyota capability pack can be used for different responsibilities, such as mobility decisions, financing-candidate ranking or proactive customer outreach, Toyota does not need a separate hardcoded workflow for every business question.

MLH — Build Your Hackathon A-Team with SpaceXSI
We used Cursor as a core AI coding agent throughout the hackathon for implementation, debugging and rapid iteration across the frontend and backend. We also used Grok Bot as an automated project guardian: it repeatedly checked the live application, monitored core regression paths and helped prioritize work based on the remaining hackathon time. Together they allowed our two-person team to parallelize development and continuously validate the product while building.

MLH — Best Use of Tiger Data
QuestMaster uses Tiger Data as the persistence and observability layer behind reusable teams and their execution history. Rather than treating each agent run as an isolated chat, execution data can be stored and inspected as structured activity, supporting auditability and visibility into how a team actually performed its work.

MLH — Best Use of Vultr
QuestMaster is deployed on Vultr, which provides the cloud infrastructure for our public production application. The frontend and FastAPI backend run on our Vultr instance so judges can interact with the same deployed system that we developed and tested throughout the hackathon.

MLH — Best .Tech Domain Name
Our production application is available at questmaster.tech. The domain directly reflects the product: QuestMaster is the control layer that turns business “quests” into teams, capabilities and executable workflows.