I was recently challenged to work out what it would actually take to start thinking of agents as colleagues. My first instinct was that this is a framing exercise, the kind of phrase that lands in a keynote and dies in a slide deck. That instinct lasted about thirty seconds. Take the phrase literally and it stops being a metaphor: it turns into a list of infrastructure requirements, and most of them land on the data platform team.
A colleague is only as good as what they know and what they're allowed to touch. Both of those are your problem.
The employment lifecycle, applied to agents
Read it straight and you get an operating model:
- An identity of its own, not a shared service account
- Scoped access, least privilege, same as a person
- Onboarding context, grounded on governed data, or you've hired someone who makes things up
- A supervised scope, with a named human accountable for the output
- Evaluation, some running measure of whether it's doing the job
- Deprovisioning when the role ends
This isn't my invention, and that's the reassuring part. Microsoft now treats least privilege for agents as a design requirement, with identity, scope, and tool access defined before autonomy expands, and their guidance is explicitly to govern agent identities the way you govern employees. Entra Agent ID will only let you assign an agent a low-privilege role at all. Others take the metaphor further and describe agents that get onboarded and granted their own accounts.
Five of those six items are platform work. That's the useful reframe to bring to a leadership conversation: this isn't a culture initiative, it's an access model and a context model, and it's almost certainly the foundation work you were already scoping.
I've built most of that list at least once. Some of it held up.
What worked
Real identity, enforced server side. In my banking reference platform I pulled out the persona dropdown and replaced it with Google Sign-In. The backend verifies the ID token and maps the verified email to a persona; approver-only routes 403 anything else, and the approver's verified email is what gets written into the audit record. The AI gateway I built on the same idea carries entitlements and a token budget per identity: known emails get a tier and a spend ceiling, unknown emails are rejected as unprovisioned. Offboarding is deleting a row. Boring, which is the point.
Onboarding from one governed source. The agent's table perimeter, its join model, and the knowledge-graph view are all compiled from a single ontology file, with a CI check that fails the build if any projection drifts (the details are here). Before that I hand-kept three copies, and they had already disagreed: three relationships in one place, four in another. An onboarding packet that contradicts itself looks fine right up until the new hire answers a question wrong in front of a customer.
Performance review as a running job. Every chat turn lands in BigQuery, a nightly model-as-judge scores grounding and tool use, and the result shows up in the admin view instead of a slide from six months ago. Evals belong in observability, not in a launch checklist.
Supervision that's structural rather than advisory. The data-quality steward reads failed Dataplex scans, proposes a remediation, then stops and waits for a human approver. It never writes to a financial table; the owning team executes the fix. The agent holds the recurring responsibility, the human holds the signature.
What didn't
The most instructive failure was on this blog. The RAG widget kept confidently telling readers something that had been edited out of a post months earlier. I spent real time on prompt rules and then on a groundedness verifier. The actual cause was that ingest upserted chunks but never deleted the ones that vanish when a post gets shorter, so a deleted paragraph lived on in the index and the agent faithfully quoted it. Confident and wrong, and no instruction was ever going to fix it, because the problem was the colleague's memory, not their attitude. Most RAG problems are data problems.
Second, fail-open guards. That groundedness check regenerates an answer when a claim isn't unambiguously supported, but if the verifier itself errors, the original answer ships. Correct tradeoff for a blog widget, wrong one when there's a customer on the other end. Decide which direction each guard fails before you find out the hard way.
Third, silent evaluation. My first version of the eval logger was fire-and-forget in a background thread on Cloud Run, which throttles CPU once the response is sent. The threads never ran. The performance review looked clean because it was empty, which is worse than not having one.
Where to start
Not with a task. "Summarize this" is a copilot. Pick one small recurring responsibility an agent can hold end to end with a named reviewer, then give it its own identity, a scoped read path, one governed source of context, and a score somebody actually looks at.
And be honest about the prerequisite. Atlassian's read of the field puts only 4% of companies seeing real AI ROI, with the ones that do having shifted from chasing individual productivity to using AI to facilitate teamwork, and with data silos named as a major culprit behind mediocre outcomes. Without shared governed context, agents as colleagues gets you confident, wrong colleagues, faster.
0 Comments
Leave a Comment