-
-
Founder Dashboard
-
Fleet Console
-
Generated storefront
🚀 Inspiration
Starting a business is rarely just an idea problem.
A founder may begin by asking:
What should I sell? Who are my customers? How should I price it?
But once the business starts operating, the questions change:
Why aren't we growing? Is the problem demand, margin, capacity, or retention? What should we change next?
Most AI tools help with individual pieces of this journey. They can brainstorm an idea, write marketing copy, analyse competitors, or generate a business plan. But the founder is still responsible for coordinating everything and deciding what should happen next.
We built VentureOS to explore a different idea:
What if a founder could work with an entire governed AI company instead of a single AI assistant?
For our demo, we used a real-world scenario inspired by a friend of ours who wanted to explore launching her own small business.
Instead of building around a hypothetical use case, we used her business idea to see whether VentureOS could understand a founder's context, identify the value proposition, research the market, generate useful business resources, coordinate specialised agents, and turn an idea into a more structured launch plan.
VentureOS is designed as an AI operating system for founders that can help launch a business, operate it, diagnose what is preventing it from growing, and scale it over time.
💡 What it does
VentureOS supports two connected operating modes:
Launch
A founder describes the business they want to create and provides context such as:
- goals
- target market
- budget
- capacity
- constraints
- existing resources
A CEO Orchestrator then coordinates work across a fleet of specialised agents covering:
- Market research
- Competitor analysis
- Financial planning
- Branding and growth
- Website and catalogue creation
- Outreach
- Operations planning
Rather than exposing the founder to a series of disconnected AI responses, VentureOS synthesises this work into a single founder-facing operating plan.
In our demo, we show this using our friend's business idea.
The system helps establish the business context and value proposition, performs relevant research, creates resources and deliverables, and coordinates work across specialised agents rather than relying on one general-purpose assistant.
Scale
Once the business exists, the problem changes.
The question is no longer simply:
How do I launch this?
It becomes:
What is preventing this business from growing right now?
VentureOS analyses business data to identify the binding constraint affecting growth.
That constraint could be:
- Demand
- Margin
- Capacity
- Retention
- Or another measurable bottleneck
The system can then recommend targeted experiments or interventions and evaluate their impact in subsequent cycles.
The operating loop becomes:
Measure → Diagnose → Intervene → Re-measure
Launch and Scale are therefore not two disconnected demos.
They represent two states of the same persistent company, allowing the system to retain business context and evolve with the founder over time.
🤖 The agent fleet
VentureOS is coordinated by a CEO Orchestrator rather than allowing the frontend to directly invoke individual agents.
The CEO delegates work across specialised departments and workers.
Strategy
Strategy Manager
- Market Research Agent
- Competitor Analysis Agent
- Financial Planner
Build & Growth
Build & Growth Manager
- Social & Brand Agent
- Website & Catalogue Agent
- Outreach Agent
Operations
The Operations Agent handles capacity and operational planning and reports directly to the CEO.
Each agent has a defined responsibility and capability boundary.
The goal was to make VentureOS behave less like a group chat containing multiple AI agents and more like an operating structure in which work has ownership, dependencies, context and accountability.
📐 System architecture
VentureOS uses a hierarchical multi-agent architecture built around a single founder instruction.
The founder interacts with the system through the application, while orchestration, policy enforcement, state management and agent execution remain behind a controlled backend boundary.
At a high level, the architecture includes:
- Founder-facing console
- Authentication and API layer
- Agent Gateway
- Agent Registry
- Agent Identity
- Model Armor
- CEO Orchestrator
- Strategy department
- Build & Growth department
- Operations
- Persistent company state
- Memory and retrieval
- Grounding services
- Approval-gated external actions
- Recurring Scale cycles
- Logging and tracing
- Asynchronous execution and retries
One of our main architectural decisions was to ensure that the frontend does not directly call individual agents.
Requests pass through a backend control plane so that orchestration, agent identity, policy enforcement, observability and permissions can be applied consistently.
The complete VentureOS architecture diagram is included separately with our submission.
🛠️ How we built it
VentureOS is built around the three core pieces required for the hackathon:
- Gemini 3.5 Flash as the primary reasoning model
- Google Agent Development Kit (ADK) as our agent framework
- Google Cloud for the infrastructure supporting the agent system
The agent layer is built using Google ADK, with Gemini 3.5 Flash serving as the primary runtime model.
We also integrated Gemma as a separate groundedness and validation path so that evidence-backed outputs can be evaluated independently from the primary Gemini generation path.
Google Cloud architecture
Our Google Cloud-native stack includes:
- Google ADK for agent construction and orchestration
- Gemini 3.5 Flash for primary agent reasoning
- Gemma for groundedness and validation
- Vertex AI for model infrastructure
- Cloud Run for backend and agent services
- Firestore for persistent company, workflow, task, approval, artifact, metric and experiment state
- Pub/Sub for event-driven agent workflows
- Cloud Tasks for delayed execution and retry handling
- Cloud Scheduler for recurring Scale cycles
- Agent Registry for capability discovery
- Agent Gateway for governed agent and tool traffic
- Agent Identity / IAM for access boundaries
- Model Armor for safety controls
- Memory Bank for durable agent memory
- Cloud Trace for tracing
- Cloud Logging for observability
- Firebase Authentication for user identity
The founder-facing application is built using Flutter Web.
The frontend communicates with our backend API instead of invoking individual agents directly, keeping orchestration, permissions and agent execution behind a governed boundary.
🔎 Technologies and data sources
Models and agent framework
- Gemini 3.5 Flash
- Gemma
- Google Agent Development Kit (ADK)
- Vertex AI
Google Cloud and infrastructure
- Cloud Run
- Firestore
- Pub/Sub
- Cloud Tasks
- Cloud Scheduler
- Agent Registry
- Agent Gateway
- Agent Identity / IAM
- Model Armor
- Memory Bank
- Cloud Trace
- Cloud Logging
- Firebase Authentication
Grounding and external data
VentureOS uses Google Search grounding so that research agents can work with current external information instead of relying entirely on model knowledge.
Where relevant, agents can also use data and actions from Google services including:
- Google Search
- Google Maps
- Gmail
- Google Calendar
- Google Sheets
We also use image-generation capabilities for relevant branding and business resources.
🛡️ Governed autonomy
One of the principles we kept coming back to was:
Autonomous should not mean uncontrolled.
An agent can analyse information and recommend an action without constantly interrupting the founder.
Actions that affect the outside world, however, can require explicit founder approval.
For example:
- Recommending a new price is analysis; changing the storefront price can require approval.
- Drafting an outreach message is generation; sending it to a real customer can require approval.
- Identifying a production-capacity problem is analysis; creating operational calendar events can require authorisation.
VentureOS combines these boundaries with:
- agent identity
- gateway-level policy enforcement
- Model Armor
- approval workflows
- traceable execution
This gives the agent fleet room to operate while keeping consequential actions under human control.
🧠 From chatbot to operating loop
One of the most important decisions we made was to treat Launch and Scale as two states of the same company, rather than building two unrelated workflows.
The business keeps its identity and persistent context as it moves through the system.
Launch establishes the company.
Scale repeatedly evaluates what is happening to that same company.
This pushed us away from thinking in terms of isolated prompts and towards thinking in terms of:
- persistent business state
- long-running workflows
- operating cycles
- measurable constraints
- experiments and interventions
- learning from previous business outcomes
⚡ Challenges we ran into
The hardest part was not getting an LLM to generate business advice.
It was getting multiple agents, asynchronous infrastructure, schemas, grounding, persistent state and the frontend to behave like one system.
During integration, we encountered:
- 500 errors
- 4XX request failures
- Invalid schema outputs
- Grounding failures
- Empty result sets
- Cyclic execution issues
- Failures propagating between dependent agents
- Persistent-state problems
- Agent dependency issues
- Integration failures across different parts of the stack
When ten agents operate across one workflow, a small change in one part of the system can affect several other components.
We had to think carefully about:
- Structured contracts between agents
- Schema validation
- Asynchronous execution
- Retry and recovery behaviour
- Preventing cyclic agent flows
- Maintaining persistent state across workflows
- Grounding recommendations in evidence
- Separating agent recommendations from actions requiring founder approval
There was also a major product-design challenge:
How much of a multi-agent system should the user actually see?
Showing every prompt, tool call, intermediate result, retry and failure quickly becomes overwhelming.
We eventually separated the experience into two layers:
- A Founder Dashboard, focused on business outcomes, constraints, approvals, experiments and deliverables.
- A Fleet Console, exposing the underlying CEO → Manager → Worker execution flow, including agent status, tools, failures and traces.
That allowed us to keep the system understandable for a founder while still making the underlying agentic architecture observable.
📚 What we learned
Our biggest takeaway was that building an agentic system is fundamentally different from building a chatbot.
The difficult questions quickly stopped being:
What prompt should we use?
They became:
- Who is allowed to do what?
- Which agent owns a decision?
- What happens when an agent fails?
- What information should persist into the next operating cycle?
- How do multiple agents communicate without creating cyclic dependencies?
- When should the system act autonomously?
- When should a founder approve an action?
- How do we verify that recommendations are grounded in evidence?
- How do ten agents behave like one coherent system rather than ten separate assistants?
We learned that useful autonomy requires much more than model intelligence.
It requires:
Identity. State. Orchestration. Observability. Validation. Grounding. Failure recovery. Human control.
And probably our biggest practical lesson from the hackathon was:
Integration is where the real complexity begins.
🏆 What we're proud of
VentureOS grew beyond the collection of business agents we initially imagined.
We built the foundation for a persistent system in which:
- Specialised agents have clearly defined responsibilities
- A CEO orchestrates rather than the frontend micromanaging workers
- Business state persists across workflows
- Execution can be asynchronous and event-driven
- Sensitive actions can require founder approval
- Agent activity remains observable
- Grounded research can support business decisions
- The same system can move from launching a company to repeatedly diagnosing how to grow it
The result is not simply an AI-generated business plan.
It is our prototype for an:
AI-native operating layer for running a small business.
📹 Demo
For our demo, we used a real-world scenario inspired by a friend of ours who wanted to explore launching her own business.
The video walks through:
- The founder's initial business idea and context
- The business value proposition
- How VentureOS gathers and structures relevant information
- Market and business research
- Resources generated by the system
- Coordination across specialised agents
- Founder-facing outputs
- The Founder Dashboard
- The Fleet Console
- The underlying agent architecture
- The backend implementation
- Proof that the backend is running on Google Cloud
Towards the end of the demo, we deliberately go behind the UI and show the backend and Google Cloud deployment so that the infrastructure supporting the agent workflow is visible rather than only demonstrating the frontend.
Demo video:
https://youtu.be/xsX-GY3vJJ8
✍️ Behind the build
There is also a side of this project that does not fit neatly into a short demo.
For the All Things Agentic Hackathon bonus-content submission, we documented what it was actually like for five people to build and integrate a ten-agent system in nine days.
We wrote about:
- how we divided the work
- dependencies between different parts of the system
- what happened when independently working components finally had to integrate
- cascading errors
- debugging
- cyclic flows
- late-stage integration
- what the experience taught us about building agentic systems
We Built a Ten-Agent System in Nine Days. Here's What We Learned
The article covers the less-polished side of the project: the architecture decisions, integration problems, failures and lessons that do not necessarily show up in a short demo.
🏆 Bonus submissions
Social content
Our team is also sharing VentureOS and our hackathon experience on LinkedIn using #AllThingsAgentic.
LinkedIn post:
https://lnkd.in/p/gxDBzuGc
Additional Google AI model
Alongside Gemini, we use Gemma as a separate validation and groundedness path.
This allows us to evaluate evidence-backed outputs through a different model path rather than relying entirely on the primary generation workflow.
🔮 What's next
Our next step is to deepen the Scale loop.
We want VentureOS to continuously compare experiments against actual business outcomes, learn which interventions worked, and use that history when diagnosing the company's next constraint.
As a company grows, however, not every constraint can be solved by another AI workflow.
Eventually the founder may need to grow the human team as well.
That is why one extension we want to explore is an HR & Talent Agent.
If people or skills become the company's next binding constraint, this agent could help:
- Identify the role required
- Define responsibilities
- Generate job descriptions
- Support candidate sourcing
- Assist with screening
- Coordinate interviews
Hiring decisions and sensitive actions would still remain under human control.
We also want to expand integrations across:
- Commerce
- Payments
- Marketing platforms
- Operational systems
This would allow the fleet to reason over richer real-world business signals while preserving the same governance and approval model.
Over time, VentureOS could expand its fleet as the company itself grows.
Our longer-term vision is simple:
Give a small founder access to the operational intelligence and coordination that normally requires an entire company.
🧾 Disclosures
VentureOS was developed during the All Things Agentic Hackathon submission period.
The project uses Google-provided and third-party frameworks, SDKs, APIs, libraries and cloud services as described above.
Any external libraries, dependencies or third-party code used by the project are documented in the repository and README.
💻 Repository and reproducibility
The project repository contains:
- Frontend code
- Backend services
- Agent definitions
- Infrastructure configuration
- Environment setup details
- Dependency requirements
- Step-by-step spin-up instructions
The README provides the steps required to configure and run the system, including the necessary Google Cloud services and environment variables.
Repository:
https://github.com/Riddhima-jain/VentureOS
If the repository is private, access has been shared with the required Devpost and Google hackathon review accounts.
🔗 Hosted project
Hosted project:
https://radiant-mousse-c36c1e.netlify.app/
If authentication is required, testing credentials are provided separately in the relevant Devpost submission field for judges.
👥 Team
Built by:
Riddhima Jain
Vishakha Kulkarni
Vishakha Maheshwari
Madhumitha Balaji
Kush Maniar
Built for the All Things Agentic Hackathon 2026.
Built With
- agent-gateway
- agent-registry
- cloud-run
- cloud-scheduler
- cloud-tasks
- dart
- fastapi
- firebase
- firebase-authentication
- firestore
- flutter
- gemini-3.5-flash
- gemma
- gmail-api
- google-adk
- google-calendar
- google-cloud
- google-sheets-api
- memory-bank
- model-armor
- multi-agent-systems
- pub-sub
- python
- vertex-ai
Log in or sign up for Devpost to join the conversation.