Solutions · People
All of the coordination.None of the decisions about people.
Scheduling across four calendars. The interview kit built from your real scorecard. The onboarding checklist that runs itself. Policy questions answered from your handbook, not the internet. An agent handles the logistics and a person handles the judgement. That's a boundary, not a slogan.
Coordination and drafting · a person decides about a person
- Does
- Scheduling, kits, onboarding, answers
- Does not
- Rank, score or reject a candidate
- Answers from
- Your handbook, in your repo
- Personal data
- Stays in the systems you connected
01The handoff
The logistics that eat your hiring week.
A People team is judgement plus a huge amount of coordination, and the coordination crowds out the judgement. Every job below is the coordination half, on purpose.
Job 01
Scheduling across four calendars
It finds a slot that works for the panel and the candidate, sends the invitations with the right materials attached, and redoes the whole thing when an interviewer drops out. Scheduling is the most reliable source of hiring delay, and it's pure logistics.
Job 02
Interview kits, built from the scorecard
For each stage: what the interview is testing, questions that actually test it, and what a strong and a weak answer look like. Built from your own scorecard in the repo, so a new interviewer runs the same loop as a seasoned one.
Job 03
The debrief pack
It gathers what every interviewer wrote, lines it up against the scorecard instead of by who wrote the most, and highlights where two interviewers disagreed. Surfacing disagreement is the point. Resolving it is the panel’s job.
Job 04
Onboarding that runs itself
Accounts requested, the reading list gathered, the first-week plan drafted from the role, the buddy pinged. A checklist that does the work, instead of one somebody has to remember to open.
Job 05
Policy questions, answered from your handbook
Ask in a Slack thread and the answer comes from the document in your repo, with the section quoted. If the handbook doesn't cover it, it says so and routes you to a person instead of making up a plausible policy.
Job 06
Job descriptions, drafted from the real team
Before writing the posting, it reads the roles you already have and the work that team actually does. The description matches the job, not the last posting with a similar title.
02What comes back
A kit any interviewer can run.
The output here is about the process, never the person. It makes the loop consistent and the bar explicit, which is the part a tool can genuinely improve.
Stage 2: systems design · interviewer kit
- Scorecard
- hiring/scorecards/platform.md
- Stage
- 2 of 4 · 60 minutes
- Tests
- Failure reasoning
- Status
- Draft · for review
What this stage is for: does the candidate reason about failure before they reason about throughput? It isn’t a breadth check. Stage 3 covers breadth, and asking here would duplicate it.
Open with a system they’ve actually operated, not a hypothetical. Follow the first failure mode they name all the way down. A strong answer gets more specific under pressure. A weak one gets more abstract.
Out of scope for this stage, and flagged because interviewers keep drifting into it: compensation, notice period, and anything that belongs in the recruiter conversation.
It works on the process, not the person
The kit, the schedule, the debrief structure, the onboarding plan. Each one is about how you run hiring. None is a judgement about a candidate, and that line is a deliberate product choice, not a limitation.
Your handbook is the source
Policy answers come from the document in your repo, with the section quoted. If the handbook doesn't cover a question, it goes to a person. The gap gets reported, not filled.
The same loop for every candidate
Building the kit from the scorecard isn't about speed. It means the fifteenth candidate gets the same interview as the first. That's about fairness before it's about efficiency.
03Where it reaches
Your calendar, your inbox, your applicant system.
People systems hold the most sensitive data in your company, so how the connection works matters more here than anywhere else on this site. Connect each once for the project. The credential is decrypted on our side and attached to the outbound call.
Google Workspace and Outlook
Calendars, invitations and the email thread with the candidate. Reading a calendar, booking on it and sending as you are separate actions with separate answers.
Greenhouse and other applicant systems
In the Easy connect catalogue. Click through the OAuth screen and the connection belongs to the project. It reads the pipeline and the scorecard, and writes back stage and scheduling. Whether it may write at all is your call.
Notion and Google Drive
The handbook, the scorecards, the onboarding plans. More and more, these belong in the repo instead, where a policy change is a diff with an author and a date on it.
Slack
The one live channel. People ask policy questions where they already are, and the answer comes back in the thread. Microsoft Teams is built, but stays off until your deployment turns it on.
Who the connection acts as
One project-managed connection the team shares, or personal authorization where each member acts as themselves and an automated principal can't act at all. For People systems, the second is usually right.
Easy connect covers 3,000+ apps through their own OAuth screens, and most applicant and HR systems connect that way. Where one doesn't, OpenAPI, GraphQL, raw HTTP or a remote MCP server reaches it. And if a system holds data you'd rather no agent touched, the right setup is to leave it unconnected.
04How it runs
Ask in the thread. Run onboarding on the start date.
Same session machinery, started three ways. Here, point the automated mode at logistics with a fixed date, never at anything evaluative.
01 · On demand
"How much carry-over do I have?"
Ask in a Slack thread and the answer comes from the handbook, with the section quoted. If the handbook doesn't answer it, the question goes to a person instead of getting a guess.
02 · Human-assisted
It stops before contacting a candidate
Set anything that sends to a candidate to Ask. The run pauses at that call, showing you the message and the recipient, and picks up from that exact point once you approve.
03 · Automated
The onboarding run, on the start date
A cron trigger opens the session on day one and works through the checklist: accounts requested, reading list gathered, first-week plan drafted, buddy pinged. Fixed date, fixed list, no judgement involved.
05Control
Where we draw the line, and why it sits there.
In People work, "the agent handled it" would be the wrong answer. The controls below are platform controls. The first row is our product position.
01
It doesn't make decisions about people
No ranking, no scoring, no automated rejection, no recommendation dressed up as a summary. The jobs on this page are scheduling, drafting, gathering and answering. If you want an agent to screen candidates, that's a decision about your hiring process, and it isn't what this page is selling.
02
Approval gates are off until you turn them on
Out of the box, Machine is permissive: an action runs unless you've said otherwise. In a People project, your first change is setting every message to a candidate or an employee to Ask. It isn't done for you.
03
Each agent gets its own reach. Nothing is inherited.
The recruiting agent reaches the applicant system and the calendar. It can't reach payroll, because you didn't list payroll for it, and it can't even discover that the connector exists.
04
Connector credentials never enter the machine
The sandbox holds one project-scoped Machine token and no third-party keys. Your applicant-system credential is decrypted server-side, attached to the outbound request, then thrown away.
05
Where your data sits is your choice
Machine scopes every agent, connector and credential, and records the person or trigger, the action, the outcome and the approver. For deployment and compliance questions, talk to us. Don't rely on a claim from a marketing page.
06Other teams
Same machine. Every other team.
One project, one set of connectors, one memory that keeps growing. Each team writes the skills for its own work. Nobody builds a second system.
- SalesResearch, drafts and CRM cleanup, held for your yesOpen
- MarketingProduction work in your voice, because the voice is a fileOpen
- ProductFeedback turned into specs, with the evidence attachedOpen
- EngineeringReproduce it, patch it, open the change requestOpen
- FinanceThe close, the reconciliation and the variance note, with the working shownOpen
- ITRunbooks that run, and a platform that passes your reviewOpen
- Data ScienceA real machine, a real query, an analysis you can re-runOpen
- All solutionsEvery team on one page, plus the rules that never change between them.Open
People
Take back the weekthe coordination ate.
One governed platform for people operations. Any model, your keys, every action on the record.
- One machine per session
- Lands as a change request
- Every action recorded