When I joined my last company, my first few days were spent waiting. The docs were stale. I didn't have staging config or the right GitHub permissions. The knowledge I needed lived in people's heads, and those people were busy — the senior engineer I was meant to pair with spent my second day inside a DevOps incident. None of it was anyone's fault. It's just what onboarding looks like almost everywhere. Later I was asked to fix it, first for engineering and then for everyone, and I ended up spending about a week per new hire. So I started writing down what I was actually doing: reading a resume against the open backlog, working out who genuinely knew a service as opposed to whose name was on the file, moving an intro because the person was mid-incident. After enough of these the shape was obvious — Knowledge + People → Productivity + Navigation. Every hour I spent was navigating knowledge and people so somebody could feel useful and know who to ask.
What struck me is that none of those questions have lookup answers. Which of three open tickets can this specific person finish by Friday, given their background and the training they don't hold yet? Who actually knows this service — the CODEOWNERS entry, or the person with forty-seven commits in ninety days? If the obvious expert is carrying the pager all week, who is the next best person to send a joiner to? You can't hard-code those, because the right answer moves with the evidence. That is what makes onboarding agent territory rather than workflow territory, and it's why I built Onboarding Agent for the Taskmaster track of Google's hackathon, where the entry point is an event rather than a chat box and the system is expected to decide for itself what happens next.
It runs on Google ADK 2.8 with Gemini 3.5 Flash. The load-bearing decision was to use a collaborative coordinator instead of a workflow graph: in a graph I would write the reconciliation rules and the model would execute them, so the judgement that a CODEOWNERS file is stale would live in my code rather than in the agent. Instead one root agent holds four specialists and chooses at runtime which to consult, so an engineer, a regulatory hire and a clinician genuinely take different routes through the same systems. Each specialist owns a question rather than a data source — who really knows this code, what is this person allowed to start on, who can actually be approached this week — because reconciling sources that disagree only works inside an agent holding several of them at once.
Underneath sits a tool layer the agents cannot bypass: 38 read tools generated from each system's live OpenAPI spec, four write actions that each carry an idempotency key, and retry and timeout policy in one place. Three ADK plugins enforce what instructions couldn't — budget caps, detection of silently truncated responses, and a rule that no action may be taken unless some recorded decision names its subject. A new-hire event arrives over Pub/Sub and the whole thing runs on Cloud Run, scaling to zero between hires.
The point is that it doesn't produce a report. It assigns the task, books the meeting in both calendars, and posts an introduction on the ticket so the person you're being sent to knows you're coming — and each of those traces back to a recorded judgement with its evidence attached. When it genuinely can't determine something, it says so and routes the question to a named person instead of guessing. A new hire opens one page on day one and finds real work already assigned and a real conversation already booked, which is roughly the week I wish somebody had given me.
NOTE: I created this piece of content for the purposes of entering Google's "All Things Agentic" hackathon. #AllThingsAgenticHackathon
