A technology company grows, and the founder ends up doing the marketing, the technology watch, the contracts and the books. It is real work. It has to be done, it has to be done well, and it is not the work you are best at. 𝗛𝗶𝗿𝗶𝗻𝗴 𝗳𝗼𝗿 𝗶𝘁 𝘄𝗮𝘀 𝗼𝘂𝘁 𝗼𝗳 𝗯𝘂𝗱𝗴𝗲𝘁 𝘁𝗵𝗲𝗻, and onboarding takes months we did not have at a moment when moving fast was the entire strategy. 𝗗𝗼 𝘄𝗵𝗮𝘁 𝘆𝗼𝘂 𝗱𝗼 𝗯𝗲𝘀𝘁 𝗮𝗻𝗱 𝗱𝗲𝗹𝗲𝗴𝗮𝘁𝗲 𝘁𝗵𝗲 𝗿𝗲𝘀𝘁, 𝗲𝘅𝗰𝗲𝗽𝘁 𝘁𝗵𝗲𝗿𝗲 𝘄𝗮𝘀 𝗻𝗼𝗯𝗼𝗱𝘆 𝘁𝗼 𝗱𝗲𝗹𝗲𝗴𝗮𝘁𝗲 𝘁𝗼 𝘆𝗲𝘁.

So we opened a department and staffed it with virtual employees. And somewhere in the first weeks the interesting thing happened. I stopped asking what the agents could do, and started asking what our org chart could look like now that a seat runs on a budget we are comfortable with.

That is the shift worth talking about. An org chart used to be a function of payroll: you got the departments you could afford, and everything else waited until you grew. We now have seats for work that would never have justified a hire, which means the people
we do hire spend their time on what only people can do. What is not cheap is trust, and trust turns out to be the entire job.

Two of them work here today:

- 𝗟𝗶𝗹𝗼 holds the engineering seat and works on our repositories.
- 𝗟𝗶𝗹𝗮 holds the newsroom seat and covers technology watch, content and documents.

They reach us through a messaging app, Signal in our case, and the whole team shares one e2-medium instance. And like every employee, each has a name, a job description, a manager who reviews the work, an identity of its own, and exactly the accesses that role requires.

That last part is where it stops being a demo. The moment a virtual employee holds credentials you are not designing a workflow anymore, you are running an identity, and everything you know about onboarding a colleague suddenly applies:

- A virtual employee is not a persona, it is a perimeter.
- Hiring is provisioning credentials.
- Training is restricting, then widening.
- Promoting is granting write access.
- Firing is revoking.

𝗬𝗼𝘂 𝗰𝗮𝗻 𝗸𝗲𝗲𝗽 𝗰𝗮𝗹𝗹𝗶𝗻𝗴 𝘁𝗵𝗲𝗺 𝗮𝗴𝗲𝗻𝘁𝘀. 𝗧𝗵𝗲𝘆 𝘀𝘁𝗶𝗹𝗹 𝗻𝗲𝗲𝗱 𝗛𝗥, 𝗮𝗻𝗱 𝘁𝗵𝗮𝘁 𝗛𝗥 𝗶𝘀 𝗺𝗼𝘀𝘁𝗹𝘆 𝗜𝗔𝗠 𝘄𝗶𝘁𝗵 𝗯𝗲𝘁𝘁𝗲𝗿 𝗨𝗫.

You will leave with:

1. The architecture on 𝗚𝗼𝗼𝗴𝗹𝗲 𝗖𝗹𝗼𝘂𝗱, and the budget it actually runs on
2. Our recipe for splitting the work between 𝗚𝗲𝗺𝗶𝗻𝗶, 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲 and 𝗛𝗲𝗿𝗺𝗲𝘀, an open source agent runtime, and what it costs to get that split wrong
3. What it really takes to drive 𝗚𝗼𝗼𝗴𝗹𝗲 𝗪𝗼𝗿𝗸𝘀𝗽𝗮𝗰𝗲 from an agent, and where it fights back
4. The job description template we fill in before handing any agent a key, and the onboarding path that takes a new hire from read only to trusted
5. The failures that showed us where the real edges are

𝗣𝗿𝗲𝗳𝗲𝗿𝗿𝗲𝗱 𝗳𝗼𝗿𝗺𝗮𝘁: 30 to 45 minute technical session. Adapts to a 15 to 20 minute lightning talk by keeping the thesis and the three failures and dropping the architecture walkthrough.

𝗔𝘂𝗱𝗶𝗲𝗻𝗰𝗲: founders, developers, architects, and non technical builders. 𝗡𝗼 𝗽𝗿𝗲𝗿𝗲𝗾𝘂𝗶𝘀𝗶𝘁𝗲 beyond general cloud familiarity. The content applies whether or not you run on Google Cloud, though the examples are on GCP.

Field report, not a product pitch. Nothing shown is for sale. The department described runs our company day to day, it is not a mock up built for the stage. The agent layer is open source and the talk is not tied to it: 𝘁𝗵𝗲 𝗮𝗽𝗽𝗿𝗼𝗮𝗰𝗵 𝗮𝗽𝗽𝗹𝗶𝗲𝘀 𝘁𝗼 𝗮𝗻𝘆 𝗿𝘂𝗻𝘁𝗶𝗺𝗲.

Demo is recorded, with a live version if the room network allows. No client data is shown, and no client or project is named.

𝗙𝗶𝗿𝘀𝘁 𝗽𝘂𝗯𝗹𝗶𝗰 𝗱𝗲𝗹𝗶𝘃𝗲𝗿𝘆. 𝗖𝗮𝗻 𝗯𝗲 𝗽𝗿𝗲𝘀𝗲𝗻𝘁𝗲𝗱 𝗶𝗻 𝗘𝗻𝗴𝗹𝗶𝘀𝗵 𝗼𝗿 𝗙𝗿𝗲𝗻𝗰𝗵, 𝘀𝘂𝗯𝗺𝗶𝘁𝘁𝗲𝗱 𝗶𝗻 𝗘𝗻𝗴𝗹𝗶𝘀𝗵.