Hire to productivity: treat capacity as more than a headcount

A solo founder may not be hiring employees every month, but still has to acquire capacity: a contractor for a delivery peak, an accountant for a close, or a specialist for a problem outside their expertise. The useful question is not “can an agent hire someone?” It is “can the system prepare the evidence and coordination needed to bring the right person into productive work?”

The prototype has a requisition-to-onboarding lifecycle, candidate score records and a review gate. It is a local demonstration of controlled workflow transitions, not a validated hiring decision system.

Start with the work that is missing

For the sample studio, two accepted pilots overlap. The missing capacity is a person who can prepare document-ingestion tests for a specific two-week window. The agent can assemble that need from the delivery plan instead of generating a vague job description.

capacity_request:
  work: prepare document-ingestion evaluation set
  period: two weeks
  expected_output: reviewed test corpus and failure report
  access_needed: redacted documents and staging environment
  approval_owner: founder
  engagement_type: contractor

This is an example intake contract. It describes an output and access requirement rather than inferring personal characteristics. The hiring loop should link it back to the work order and approved spend plan.

What the prototype can walk through

A requisition moves from draft to approval, then a job posting can be created. A candidate proceeds through screening, shortlist, interview, offer and hire. Onboarding creates an employee-role record and advances it to active.

The fixture makes this sequence executable:

from h2p.pipeline import build_h2p_pipeline

workforce, dispatcher = build_h2p_pipeline()
seed = workforce.seed("studio-demo")
result = workforce.hire(seed, tenant_id="studio-demo")
assert result.allowed

The scores and recommendations in the helper are controlled inputs. A passing lifecycle test proves that records and gates connect. It does not establish that a model can assess a candidate fairly or accurately.

Where AI assistance is useful

The agent can compare the role requirements with supplied experience, identify missing evidence, draft consistent interview questions and prepare a summary for the founder. The summary should link each claim to the candidate's material or interview evidence.

The decision packet should separate observed evidence from interpretation. “Implemented three ingestion pipelines” is a claim with a source. “Will thrive under pressure” is a much less grounded inference. The system should not turn an unsupported personality judgement into a rejection criterion.

A fairness number is not a fairness guarantee

The prototype includes a bias-audit record and a threshold-based gate. Its example uses an adverse-impact ratio threshold of 0.8 and can escalate records marked for review. That is a demonstration of a policy reading recorded evidence; the ratio is currently a supplied input.

For a real evaluation, I would need to define the cohort, decision stage, sample size, data permissions and statistical uncertainty. A small sample can produce unstable ratios. An overall ratio can also hide failures in particular roles or candidate groups. The first live version should therefore assist human review, with consistent job-related criteria and a way to correct the underlying evidence.

The gate must also derive its inputs from an auditable evaluation process. Letting a scoring agent pass its own reassuring fairness value would remove the independent check.

Onboarding is an access-control workflow

“Candidate hired” should trigger a bounded onboarding plan: approved agreement, start date, required accounts, least-privilege access, orientation material and an owner for the first deliverable. Account creation and access changes are separate actions with receipts.

Calendar, identity-provider, repository and document-store connectors are extension work for this platform. They should not be implied by a seeded employee record becoming active. Offboarding needs the corresponding revocation and asset-return path, not just a status change.

Productivity closes the loop

I want the first accepted deliverable, time spent obtaining access, rework and remaining capacity to feed the next planning cycle. That creates a connection from the original delivery need to the capacity that was actually available.

Payroll-to-finance wiring is deferred in the current slice. So is a full skills and utilisation model. For a solo studio, the first experiment can stay narrow: prepare one role-specific brief, keep the founder in the selection decision, and coordinate onboarding for one approved contractor. The success measure is useful work becoming possible with less repeated administration, not the number of candidates automatically scored.

Start with a capacity problem that has evidence

A founder may say “I need another engineer” when the actual problem is an unclear offering, repeated rework or a temporary support spike. The hiring loop should begin with the work: backlog, required skills, available hours, deadline and the reason existing capacity cannot cover it. An agent can prepare that packet from delivery and support records.

For the studio example, suppose two accepted pilots require an additional 40 hours of frontend integration over three weeks. The decision may be a scoped contractor engagement rather than a permanent hire. The platform should make the alternatives comparable without pretending to make the founder's employment decision.

A proposed capacity packet can include:

{
  "need": "frontend integration for two accepted pilots",
  "window_days": 21,
  "estimated_hours": 40,
  "required_evidence": ["relevant work sample", "availability", "delivery estimate"],
  "alternatives": ["reduce scope by agreement", "contract a specialist", "reschedule"],
  "decision_owner": "founder"
}

The estimates are planning assumptions for the example. Tie them to work-order IDs so the need can be revised if one project slips or its scope changes.

Use structured evidence without pretending a score is a decision

The agent can extract relevant experience from a supplied application, organise a work sample and identify unanswered job-related questions. Keep missing evidence separate from negative evidence. A blank field about a tool is not proof the person cannot use it.

The existing prototype's supplied scores are useful for testing state transitions, but they do not establish predictive validity or fairness. A production workflow should preserve the assessment rubric, reviewer identity, evidence references and decision rationale. Sensitive personal attributes do not belong in a generic capability score.

The scheduling connector also needs careful identity handling. A candidate's calendar address may differ from their application address. Confirm the intended attendee and timezone rather than sending an invitation to the first email-like string found in a resume.

Productivity begins with access and a first accepted task

An offer marked accepted does not mean the person can work. The onboarding checklist should cover the agreed scope, repository or workspace access, development setup, a named reviewer and the first deliverable. Some prerequisites require a real access receipt, not a checkbox set by the agent.

from company_lab.business import onboarding_ready

required = {"scope_accepted", "workspace_access", "reviewer_assigned"}
completed = {"scope_accepted": True, "reviewer_assigned": True}
assert not onboarding_ready(required, completed)
completed["workspace_access"] = True
assert onboarding_ready(required, completed)

This small gate can drive a useful operator view: “Engagement accepted; workspace access pending; first task not yet started.” It prevents a dashboard from counting the person as available capacity too early.

Connect the lifecycle to offboarding

Every granted account or permission should have an owner and a scope. A temporary contractor's access should be linked to the engagement end condition. Offboarding then becomes a set of verifiable revocations and handover checks rather than a reminder buried in a calendar.

The agent may prepare access requests and summarise missing prerequisites. The identity provider or repository system executes approved changes and returns receipts. An unverified chat message saying “access removed” is not equivalent to a confirmed revocation. A failed revocation stays visible as an exception.

Measure the coordination work the platform can improve

Useful measures include time to a reviewable capacity brief, missing-context frequency, scheduling corrections, time from accepted engagement to usable access and completion of the first accepted task. These do not require claiming that the agent selected the best candidate.

The implementation exercise is a contractor whose start date arrives before repository access is granted. The system should preserve the accepted engagement, show the blocked prerequisite and notify the responsible operator once with a useful action. It should not reschedule the person automatically, claim they are productive or repeatedly generate a new onboarding plan.