This is week six of the SwarmCraft workflow replacement case-study series. Each week is dedicated to completing one workflow replacement project end to end, then showing the finished build, implementation evidence, and what the completed software can actually do.
The workflow is candidate screening: a recruiter receives new application or stage-change activity from Greenhouse, reviews an AI-prepared candidate packet, makes the human decision, and keeps the audit trail tied to source evidence.
This is also where the current "agentic recruiting" language becomes useful. A useful AI recruiting agent should not just generate a screening paragraph. It should perform a sequence of recruiting operations: detect candidate activity, pull source context, evaluate against a role rubric, flag exceptions, route human review, prepare next-step actions, and write approved outcomes back to the ATS.
The target is not to clone Greenhouse. Greenhouse remains the system of record for candidates, applications, jobs, stages, scorecards, notes, and dispositions. The more interesting move is to own the focused screening surface around it: the queue, evidence packet, decision boundary, audit trail, and integration behavior that recruiters touch every day.
If you want the broader category context first, start with Best recruitment software. This article is the implementation-led view: what one candidate screening workflow looks like when it becomes owned software instead of another rented workflow add-on.
Greenhouse is a good source-product boundary for this case study because its own API overview describes APIs for accessing and updating Greenhouse data, including candidate information and application movement. Its Harvest v3 documentation and recruiting webhooks documentation make the same integration shape explicit: a focused app can receive recruiting events, retrieve source records, and write approved changes back without replacing the ATS itself.
Project stats
| Stat | Week 06 result |
|---|---|
| Implemented tickets | 39 |
| Final board state | 39 done / 0 open |
| Build runner | OpenAI Codex CLI |
| Driver evidence span | 9h 4m, including recovery and final resume |
| Final continuation runtime | 5m 44s |
| Tracked files | 220 |
| Tracked text lines | 30,871 |
| Test and spec files | 32 |
| Database migrations | 9 |
| System-test evidence screenshots | 8 |
| SwarmCraft setup screenshots | 2 |
One evidence note: the run recovered from a packet checklist text-sync error before the final successful resume, so the cost telemetry only covers the last continuation. This article does not claim a full run request count. It uses the directly supported evidence instead: final board state, target repo contents, tests, migrations, screenshots, and the successful driver manifest.
The useful part is not that an AI agent generated a recruiting screen. The useful part is that the Week 06 build turned a recruitment operations scenario into a repository with Greenhouse integration adapters, webhook intake, candidate context sync, server-side screening policy, human decision endpoints, writeback retry records, audit history, role-aware browser screens, Playwright proof screenshots, production configuration notes, health checks, and runbooks.
That is the difference between "AI summarized a resume" and a candidate screening workflow that can be inspected, tested, and improved.
The candidate screening workflow we built
The finished app handles a focused applicant screening workflow with four recruiting roles.
| Role | Responsibility |
|---|---|
| Recruiter | Owns the screening queue, reviews evidence-backed packets, approves or rejects recommendations, and monitors writeback status. |
| Hiring manager | Reviews candidate packets when extra role-fit judgment is needed and can make final workflow decisions when authorized. |
| Interviewer | Contributes scorecard context and interview-readiness evidence without owning the final screening decision. |
| Recruiting coordinator | Can triage queue status and handoffs without necessarily receiving full packet evidence or decision controls. |
The candidate screening process follows a focused recruiting workflow:
- Greenhouse sends a new application or application stage-change webhook.
- The API verifies and stores webhook intake metadata without keeping raw webhook bodies.
- The integration layer uses Harvest context to retrieve candidate, application, job, stage, attachment, and scorecard records.
- The API assembles a versioned screening packet with a recommendation, confidence, rubric evaluations, source evidence, and policy flags.
- Missing evidence, incomplete rubric work, duplicate-candidate signals, knockout criteria, and human-review exceptions become visible workflow states.
- The recruiter or hiring manager reviews the packet in a queue designed for screening work, not generic tasks.
- The browser separates read-only agent evidence from final decision actions.
- Approval and rejection require a confirmation dialog and an authenticated human actor.
- The API writes one final workflow decision, copies recommendation evidence onto the decision, and appends workflow audit events.
- When Greenhouse writeback is enabled, the API creates retry-safe operations for stage movement, candidate notes, or rejection disposition.
- Recruiters can inspect the audit and status timeline later, including actor, outcome, source references, and writeback status.
That is what makes this candidate screening automation more than a resume-ranking demo. The agent prepares the work. The person owns the outcome. The system records enough evidence to explain the decision later.
The queue is the recruiting operations surface
Most candidate screening workflow problems are not caused by a missing "summarize resume" button. They happen because the recruiter has to move across applications, resumes, scorecards, rubrics, hiring-manager notes, emails, calendar steps, and ATS status changes before one candidate can move forward.
The Week 06 app makes the screening queue the center of the workflow.
The queue contains the candidate list, status tabs, packet counts, role, recommendation strength, confidence, SLA text, exception reasons, and the selected candidate packet. The packet panel shows profile summary, application answers, resume evidence, scorecard evidence, role criteria alignment, policy checks, next recruiter steps, and evidence markers such as E1, E2, and E3.
That evidence-marker detail matters. Agentic recruiting is only credible when a recruiter can see what the agent used. A recommendation with no citations is just another black box. A recommendation tied to application answers, resume excerpts, scorecards, and job criteria is reviewable work.
The screen also keeps the system-of-record boundary visible. The app can present, route, and decide the screening packet, but the Greenhouse writeback is a downstream action after human approval.
Human approval is a product feature
The most important part of the workflow is not the recommendation. It is the boundary around the recommendation.
The browser keeps read-only packet evidence separate from the Decision action panel. The available actions are direct recruiting operations: approve recommendation, reject candidate, request clarification, or send to hiring-manager review. Approval and rejection both open confirmation dialogs before local confirmation is captured.
That dialog repeats the candidate, role, action, downstream effect, and human-approval requirement. The API enforces the same principle. Automated recommendation logic never advances or rejects a candidate by itself. Final outcomes require the decision endpoint, a reviewer reason, and an authenticated human actor.
After approval, the UI shows the result as an auditable workflow state rather than a vanished task.
The approved state includes the decision, actor, reason, workflow status, and source evidence copied from the recommendation. That is the operating value: a recruiter can explain why the packet advanced without reopening raw candidate documents or trusting memory.
Exceptions are first-class workflow states
Candidate screening gets risky when automation hides uncertainty. A good applicant screening workflow should expose uncertainty early and force it into the right human review path.
The Week 06 build makes exception and judgment states visible in the same queue.
The exception example shows a packet that needs human input. It surfaces missing information, knockout criteria, rubric gaps, and policy checks instead of pretending the recommendation is complete. That gives the recruiter the right work to do: resolve the judgment issue, send the packet to a hiring manager, request clarification, or record a decision with a reason.
Rejection uses the same human boundary.
After confirmation, the rejected packet remains inspectable.
This is important commercially. Many AI screening demos only show the happy path: rank candidates, advance the best one, move on. Real recruitment operations need the unhappy path just as much. Missing evidence, knockout criteria, duplicate-candidate signals, rejected recommendations, and reviewer overrides all need states, rules, and audit records.
Audit and status stay visible after the decision
The Playwright system tests prove that audit and status evidence remains visible after action, navigation, reload, and revisiting the queue route.
The audit timeline labels the source of each event:
| Timeline label | Meaning |
|---|---|
| Agent suggestion | The screening agent generated or updated a recommendation. |
| Workflow status | API-owned workflow policy changed or explained packet state. |
| Human-approved action | A reviewer recorded a human decision. |
| Greenhouse writeback | A downstream integration wrote, skipped, retried, or reported an outcome. |
The revisited route proves this is not just a transient component state.
That persistence proof is what a candidate evaluation workflow needs. The user should not have to trust a notification toast. They should be able to revisit the packet and see the recommendation, decision, source evidence, actor, outcome, and writeback status later.
What the custom candidate screening app includes
The Week 06 build produced a working browser app, API boundary, database schema, Greenhouse integration layer, and test evidence. It is not a static recruiting mockup.
| Area | Implemented capability |
|---|---|
| Recruiter queue | Status tabs, packet counts, candidate rows, recommendation strength, confidence, SLA text, exception reasons, selected packet preview, and empty/loading states. |
| Evidence-backed packet | Candidate profile, application answers, resume evidence, scorecard evidence, role criteria alignment, policy checks, recommendation citations, and next recruiter steps. |
| Human decision boundary | Approve and reject actions require confirmation, reviewer attribution, decision reasons, and API-owned decision writes. |
| Workflow policy | Server-side validation for new_packet, needs_review, approved, rejected, and exception states, including blocking missing-evidence and duplicate-candidate conditions. |
| Role authorization | Recruiters and hiring managers can review and decide packets; coordinators can be restricted to queue-level triage; authorization failures are handled before packet data is read. |
| Greenhouse intake | Webhook endpoint, event id handling, body digests, duplicate and replay detection, supported application-created and stage-change events, and signature verification in HTTP mode. |
| Harvest context sync | Candidate, application, job, stage, attachment, and scorecard reads through mockable Greenhouse adapters, with source-status rows for troubleshooting. |
| Greenhouse writeback | Post-decision stage update, candidate note, and rejection disposition operations with local idempotency keys, bounded retry attempts, safe summaries, and external result ids. |
| Audit history | Workflow audit events, copied source references, decision audit history, integration audit records, request correlation, and security audit events. |
| Sensitive data handling | Audit rows avoid API tokens, webhook signatures, raw resumes, candidate note bodies, raw Harvest responses, candidate names, candidate emails, and sensitive request bodies. |
| Browser proof | Playwright system tests drive happy-path approval, exception/rejection, reload persistence, and audit/status visibility while writing stable screenshots. |
| Operations | Health and readiness endpoints, Docker Compose PostgreSQL, production Dockerfiles, Kubernetes manifests, CI workflow, environment docs, rollback notes, and operational runbooks. |
The scenario also names interview scheduling, email delivery, and Slack or Microsoft Teams notifications as useful recruitment operations dependencies. The implemented repo does not fake those services. It focuses the shipped integration work on Greenhouse webhook intake, Harvest context sync, and writeback behavior first, while keeping notification outcomes visible through the recruiter UI and workflow audit trail.
That is the right order for this slice. If the system cannot prove what candidate evidence was used and who approved the outcome, adding calendar and chat automation would only move ambiguity into more tools.
Technology implemented
The repository is a small production-style monorepo with clear ownership boundaries.
| Layer | Technology |
|---|---|
| Web app | React 18, Vite 5, recruiter-facing route shell, runtime API configuration, unit tests, and Playwright system tests |
| API | Spring Boot 3.4, Java 17, Spring MVC, JDBC repositories, HttpOnly session cookies, request correlation, and structured audit behavior |
| Persistence | PostgreSQL with Flyway migrations for roles, security audit events, candidate screening workflow state, audit sources, Greenhouse webhook events, writeback operations, integration audit records, and decision exception audit types |
| Workflow rules | API-owned screening policy, packet validation, decision authorization, source-reference snapshots, one-decision-per-packet enforcement, and exception handling |
| Greenhouse integration | Mock and HTTP adapter modes, Harvest read adapters, webhook verifier, webhook intake controller, context sync service, writeback service, retry service, and integration audit repository |
| Local runtime | npm workspaces, Maven, Docker Compose PostgreSQL, .env.example, seeded local users, web server on localhost:3000, API on localhost:8080/api |
| CI and operations | Build/test workflows, Dockerfiles, production manifests, health/readiness checks, rollback guidance, operational health runbook, and production configuration notes |
| Documentation | Feature notes, API contracts, schema docs, testing guide, Greenhouse integration setup, validation guide, security audit notes, and runbooks |
The implementation keeps browser presentation in apps/web and server-side workflow rules in apps/api. React renders the queue and confirmation behavior, but it does not own the screening state machine, evidence validation, authorization, or Greenhouse writeback rules.
That split matters. A future change to scorecard evidence, duplicate detection, Greenhouse retry behavior, reviewer permissions, or audit retention has a clear owner.
What the browser evidence proves
The committed Playwright evidence covers eight candidate screening screenshots:
- signed-in recruiter queue with Avery Chen selected and ready for review
- approval confirmation before advancement
- approved outcome after confirmation, navigation, and reload
- needs-human-input packet with rubric gaps and exception context
- rejection confirmation with reviewer note
- rejected outcome after confirmation, navigation, and reload
- approved audit/status timeline with source evidence
- revisited audit/status timeline after reload and returning to the queue
The system tests build the actual Vite app, fulfill deterministic app and API routes inside Playwright, sign in as the seeded recruiter user, drive the workflow, and verify the screenshot files exist and are not empty. No live API server or database is required for those proof screenshots because the Playwright runner mocks the API responses for deterministic browser evidence.
That does not replace API tests. The target repo also includes Spring tests for workflow policy, controller contracts, repository behavior, migration constraints, Greenhouse adapter configuration, webhook verification, HTTP Harvest calls, writeback service behavior, integration audit, authentication flow, and security audit redaction.
The browser screenshots answer the reader-facing question: can someone inspect the finished workflow and understand what was built? The API tests answer the engineering question: do the server-side rules, contracts, and persistence boundaries hold?
How SwarmCraft structured the build
SwarmCraft started by turning the recruitment operations scenario into a project called Agentic Candidate Screening.
The generated board started with 39 tickets. Those tickets covered repo setup, role access, session security, candidate screening domain schema, workflow policy, API contracts, Greenhouse webhooks, Harvest sync, writeback retries, integration audit, recruiter UI, confirmation dialogs, audit timelines, Playwright evidence, CI, production hardening, observability, health checks, and runbooks.
The final run state shows all 39 tickets in Done with no open work left. The target repo is clean, and the generated screenshots exist in the target repo under docs/testing/screenshots/.
That is the sale for new readers: SwarmCraft is not a generic chat window asked to "make a recruiting app." It is a structured workflow build system that turns a narrow operating problem into tickets, implementation packets, validation commands, browser evidence, and a repository that can be reviewed like ordinary software.
What must be true before you retire the screening surface
Candidate data, dispositions, communications, and hiring decisions should not move through an improvised cutover. Keep the ATS during discovery and parallel operation while the team maps which requisition, career-site, sourcing, offer, reporting, compliance, onboarding, and administration capabilities are actually used—and whether each belongs in the owned operation or with a specialist provider.
The screening surface becomes a practical first exit when the operating problem is explicit:
- the ATS is trusted, but screening work happens around it
- recruiters repeatedly inspect the same candidate evidence by hand
- AI recommendations are not trusted because they do not cite sources
- hiring managers and recruiters do not share one review queue
- exception candidates fall between tools and messages
- advancement, rejection, notes, and dispositions require manual duplicate entry
- reviewers need a visible human approval trail
- the business wants the screening rules to match its own rubric and risk policy
- the team can keep Greenhouse as a temporary migration source while the screening surface becomes owned software
Before removing the incumbent surface, run representative candidates through both paths, reconcile advancement, rejection, notes, dispositions, and communications, prove role and privacy controls, and rehearse recovery. That first replacement creates the evidence needed to decide whether the broader candidate record should migrate next instead of making the ATS a permanent dependency by default.
If the candidate record, regulatory duties, or wider recruitment operation are not yet understood well enough to design that sequence, Deep Discovery can establish the smallest safe boundary and the staged path out before implementation begins.
For readers comparing the broader recruitment stack, Best recruitment software, Greenhouse alternatives, Lever competitors, similar to Workable, and Recruitment workflow sprawl cover the buying and switching question from different angles. This article is narrower: what one candidate screening workflow looks like when it becomes owned software.
What this says about AI-built workflow software
The Week 06 result is commercially interesting because it shows a practical version of agentic recruiting.
The AI does not replace the recruiter. It sequences the work around the recruiter:
- receive a recruiting event
- gather candidate context
- assemble a screening packet
- evaluate against a role rubric
- cite source evidence
- flag exceptions
- route human review
- require human approval or rejection
- write approved updates back to the ATS
- keep an audit trail of recommendations, evidence, decisions, retries, and writebacks
That is the useful definition of an AI agent in recruitment operations. It is not a chatbot making a hiring decision. It is a coordinated workflow that prepares the decision, explains its evidence, and waits for the accountable person to act.
It is also why "AI built a CRUD app" is the wrong frame. The useful work is not the candidate table. The useful work is the workflow state around the table: Greenhouse intake, source evidence, rubric evaluation, exception policy, human decision authority, writeback idempotency, audit history, role access, and proof screenshots.
What operator-builders should take from week six
Candidate screening automation works when the trigger, source records, role rubric, exception policy, reviewer authority, writeback boundary, and audit expectations are clear.
If those pieces are fuzzy, AI will only make the screening process look faster while spreading uncertainty across more tools. If those pieces are clear, a focused candidate screening workflow can remove a lot of recruiting drag without replacing the system of record.
That is the core SwarmCraft pattern: keep the trusted platform where it belongs, then own the workflow surface where the operating pain actually lives.
Choose a discovery route
If interviews, source material, record ownership, controls, or migration need structured review, explore Deep Discovery. It can investigate whether to keep, integrate, migrate, or own records without presuming replacement is safe. Deep Discovery is currently available through a limited account-enabled rollout.
