model: opusSynthesizes findings into coherent argument. Decides when a question has been answered well enough.
A seven-agent system I built to think more rigorously about the questions that matter to me.
I run the platforms, data, and AI behind HR at one of Indonesia's largest telcos. Fourteen years in people technology — from configuring SAP HCM line by line to leading post-merger people systems after the XL–Smartfren consolidation.
The questions that keep me up aren't the platform ones anymore. They're about what happens when AI starts shaping decisions in organizations — who gets hired, how performance is judged, when humans defer to algorithms and when they shouldn't.
These questions sit at the intersection of organizational behavior, AI research, and information systems — a space producing new work faster than any single person can read.
So I built a research office.
“Not to replace my reading, but to make my reading more deliberate. The system doesn't tell me what to think. It shows me what the field has already thought about.”
What follows is how it works, and what I'm learning from building it.
Seven specialized agents, each with a narrow role and restricted tools. They don't improvise. They don't have access to the open web. They work from a fixed set of academic databases — OpenAlex, Crossref, Semantic Scholar, Unpaywall — all free and open.
model: opusSynthesizes findings into coherent argument. Decides when a question has been answered well enough.
model: sonnetSearches four open academic APIs for papers matching the research question. Returns a shortlist.
model: sonnetChecks whether paper claims match the evidence provided. Flags overreach, weak causation, small-n.
model: opusMaps conceptual relationships across papers. Surfaces when two fields use different words for the same idea.
model: sonnetEvaluates research design: sample, controls, replicability. Flags methodological red flags.
model: opusReads Prof. Hadi's synthesis as an adversarial reviewer. “What's weak here? What alternative explanation did you miss?”
model: sonnetTracks budget per task. When a task hits $5 (API-equivalent), Lukas stops the pipeline. Forces me to see cost-of-depth explicitly.
Three agents use Claude Opus; four use Sonnet. This is a deliberate asymmetry. Synthesis, theory-building, and critical review deserve the deeper model. Scouting and validation are faster, cheaper tasks where Sonnet performs well.
Each pipeline lives in its own Linux user with memory limits and restricted tool access. Research Office can't touch Studio Lala or Daraloop files.
Every agent call is priced against a $5 cap. Lukas halts the pipeline before overrun. API cost tracked per task in a JSONL ledger. Daily aggregates feed a cost dashboard.
Public dashboard shows agent names and status only. No task content. Admin endpoint requires SSO. Everything leaks through one chokepoint.
STACK: Python · Claude API (via subscription) · systemd · nginx reverse proxy · Three.js 3D office visualization · Private GitHub repo for nightly knowledge backup
I'm an infrastructure person by training — fourteen years in HR technology architecture, SAP SuccessFactors implementations, data accuracy frameworks for post-merger integration. Building Research Office in a week was partly a technical exercise.
But the research questions kept pulling me back.
Prof. Hadi doesn't “think.” Sari doesn't “search.” These are prompts with tool restrictions. Yet the frame of a “team” made me design the system with checks that a single-prompt pipeline would skip. Kirana reviews Prof. Hadi. Vina checks Sari. Lukas watches everyone. The metaphor forced accountability structures I wouldn't have added otherwise.
This is probably the most interesting thing I've learned about human-AI collaboration from the inside: the interface shapes the governance.
Lukas's $5 cap feels restrictive until you watch what happens when it hits. The pipeline stops mid-synthesis. I have to decide: fund another run, or accept the partial answer.
Both choices sharpen my thinking. Unlimited budget would let me defer that decision indefinitely — which is the real cost of cheap AI inference.
Research Office doesn't recommend what I should read. It shows me what's been written on questions I'm curious about. After one task on “calibrated reliance,” my decision log reads: “I thought this was a trust problem. The field thinks it's a metacognition problem. I need to re-read Dunning & Kruger before I keep going.”
That's the system working. Not giving me answers — showing me where my frame is wrong.
Research Office is a tool for a larger question: I'm exploring a PhD path focused on AI × HR, targeting Western programs for the 2027 application cycle.
The questions I keep returning to:
How do HR practitioners calibrate trust in algorithmic hiring tools over time, and what institutional structures sustain appropriate reliance vs. automation complacency?
When post-merger integration forces consolidation of people data across inherited systems, which governance patterns preserve data quality without destroying tacit knowledge?
How do mid-level managers interpret algorithmic performance signals when their judgment conflicts with model output — and what shapes whether they override, defer, or seek additional information?
These aren't settled questions. Research Office is how I'm learning the terrain before committing to a dissertation direction.
If you're a professor working at this intersection and this resonates, I'd be glad to hear from you.