In parts 1 to 3 we built one useful agent, a Cost Advisor, and made it fast and reliable. This part asks a bigger question: what if a small company had AI employees, each with their own role, a board of tickets they can be assigned to, and meetings where you can talk to all of them at once?
We built that on Google Cloud as a proof of concept, at the lowest cost we could: four AI employees on Gemini Enterprise Agent Platform's Agent Runtime, a Linear-style planner, and a meeting room. Here is how it works, what surprised us, and where we deliberately stopped short of "fully automatic".
The AI employees
The company has four AI employees next to the CEO:
- a CTO Agent for architecture and engineering decisions;
- a FinOps Lead Agent for cloud costs and savings;
- a Sales Agent for leads, outreach and proposals;
- a Marketing Agent for content and positioning.
Our first instinct was one multi-agent system with a coordinator and four sub-agents. We chose four independent agents instead, and it was the better call. Each one is its own project, scaffolded with Google's agents-cli (ADK in Python), with its own instructions, its own evaluation and its own deployment. We can change, test, redeploy or switch off the Sales Agent without touching the CTO. That is how you manage people, too.
Each agent runs on Agent Runtime (formerly Agent Engine) in europe-west1:
- it scales to zero, so an idle employee costs nothing;
- it has its own Agent Identity, a Google Cloud identity for that agent alone, so access can be granted per employee and every action is attributable;
- our Flask backend calls it over REST (
:streamQuery) with the identity of the App Engine service; no keys anywhere.
Every agent has an evaluation suite that runs before it is deployed, with three checks written for its role: is the answer useful, does it invent facts (clients, numbers, results), and does it keep to drafts only (it never claims to have sent or changed anything).
The board: projects, topics and tickets
AI employees need work, and work needs a place. We built a planner in the spirit of Linear:
- projects with a short key (ours is
CC) and topics inside them; - tickets numbered
CC-1,CC-2… with a Markdown description, a status (Backlog, To do, In progress, In review, Done), a priority and story points (1, 2, 3, 5, 8, 13); - each ticket has one assignee: the CEO or one of the AI employees;
- a workload view adds up the open points per person, agents included, so nobody (human or not) gets twelve tickets.
The board is a normal drag-and-drop board. What makes it different is the thread on each ticket.
"Ask the agent": proposals, not actions
On a ticket assigned to an agent there is an Ask button. It sends that agent the ticket, its description and the whole comment thread, with a clear instruction: propose, do not do. The agent answers in the thread with a plan, what it needs, the risks and an estimate, and the answer is marked as written by AI.
The CEO can comment back, ask again, and finally press Approve plan. Today that records the decision, with who approved what and when, and the ticket shows "Plan approved".
This is the part people usually expect to be "fully automated", and it is where we drew a line on purpose:
- an agent that only proposes cannot spend money, email a client or change a production system by mistake;
- the approval is written down, which is what you will need for audits and for trust;
- when an agent gets real tools (sending an email, opening a pull request, changing a budget), ADK's tool confirmation lets the same approval gate each risky action, one by one.
Automation is a dial, not a switch. Start with proposals, measure how often you approve them unchanged, and turn the dial when the numbers say you can.
The meeting room
Tickets are slow for discussion, so we added a meeting room. You start a meeting, invite some of the AI employees, and talk:
- to everyone: each attendee answers in turn, and each one sees what the others just said, so the Sales Agent builds on the FinOps Lead's point instead of repeating it;
- or to one attendee, and only that one answers.
Voice is the browser's own: speech recognition for what you say and a different built-in voice for each agent. It costs nothing and works well enough to test the idea. When you end the meeting, one call to Gemini Flash-Lite writes the minutes: a summary, the decisions and the action items, each with an owner. It took about 2 seconds in our test.
Then the loop closes: under the minutes, each action item can become a ticket on the board. You tick the ones worth keeping, adjust the title or the assignee and create them; they land in the Backlog, where you can ask the agent for a proposal. Again on purpose, nothing becomes a ticket without that click.
What surprised us
Cold starts are real. Scale to zero has a price: the first answer from an agent that has been idle can take long. Our very first meeting reply hit our 90-second limit; the retry answered in 14 seconds, the next in 38. The meeting room therefore asks each agent in a separate request, so one slow employee never blocks the others, and shows "Ask … again" when one does not answer in time. If you need instant answers, keep one instance warm, and pay for it.
Identities come with permissions. Deploying with Agent Identity granted each agent a set of baseline roles in the project (calling Gemini, writing logs and metrics, and a few more). That is reasonable, but our dry run did not show it. Read what the deployment template grants before you deploy, and decide it as you would for a new hire.
Deploy one at a time. Deploying the four agents in parallel failed with concurrent changes to the project's IAM policy. One after the other, it just works.
Evaluation judges need calibrating too. Our first "no invented facts" judge flagged honest proposals ("we could contact five agencies") as invented facts. The fix was in the judge's instructions: proposals and known company facts are allowed; made-up clients, numbers and results are not.
Budgets warn, they do not stop. During testing we reached the budget alert we had set for Gemini on Vertex AI. A Google Cloud budget sends alerts; it does not cap spending. For local experiments we now use the free Gemini API with sample data only, and keep Vertex AI for the deployed agents.
What it costs
The whole company is built to cost nothing when nobody uses it:
- the agents scale to zero on Agent Runtime, billed only while they work;
- each answer is one model call on Gemini Flash, a few cents at most by our estimate;
- the minutes are a single Flash-Lite call;
- voice is the browser's, the board and the meetings are a few small documents in Firestore.
Each part also has a clear upgrade path for when the idea proves itself: Gemini's Live API for natural real-time voice, agent sessions for longer memory, estimates and proposals drafted automatically for new tickets, and tools behind confirmation for real work.
What to consider before you build one
- Give every AI employee a narrow role and its own deployment. Independent agents are easier to test, change and explain than one large system.
- Decide what "done" means for an agent. Proposing, drafting and doing are three different levels of trust. Write down which level each agent has.
- Keep a human approval in the loop, and record it. It is cheap to build, and it is what makes the rest acceptable to a client or an auditor.
- Evaluate every agent before it ships, with checks for its role, not only generic quality.
- Start as a proof of concept at the lowest cost, and design every piece so it can be upgraded without a rewrite.
A virtual company is not about replacing people. It is a way to give a small team the structure of a bigger one: someone always ready to draft the plan, run the numbers or write the first version, with the CEO still deciding what happens next.
Would an AI team help yours? Plan your AI team on Google Cloud and get a rough size for a first version.