Handshake for AI Agents

Two surfaces share one session. The public board needs no account: search_jobs runs a keyword search, filter_jobs applies a facet like Remote, view_job opens a specific opportunity, and apply_to_job clicks Apply on the job detail page (which routes to Handshake's access/login screen for sign-in or account creation).

The employer side is the deeper half. From view_employer_home, your agent can list its own postings, open one, and pull up its applicants (view_job_applicants), then search them by name and reply through the application thread. Beyond applicant handling, it can search the Talent directory of student candidates (search_talent), send proactive outreach with message_student, open the create-job wizard with start_job_post, and manage campus reach: check approval status at every school, request approval at a new one, and add schools to an existing posting with post_job_to_additional_schools.

These come straight from the mapped behavior, not guesswork:

• **The employer graph hides behind one door.** A session lands on the public job board. Your agent must call view_employer_home first; without it, jobs, talent, conversations, and school approvals are unreachable.
• **School approval gates everything on the employer side.** Talent search and messaging only surface students at schools where the employer is approved (and who are visible to employers). request_school_approval is a real side effect reviewed by career centers in 1 to 5 business days, so search the school directory first so the intended row is on screen before firing it.
• **Messaging targets the first match.** message_student messages the first result matching student_name, so make the name specific enough to uniquely identify the target. Replies sent via reply_to_applicant do not count against proactive message limits.
• **Filters are dynamic and some lists settle slowly.** Call list_available_filters_job_listing in context instead of assuming a fixed filter set. The applicants list hydrates slowly (the search action builds in a leading wait), and after post_job_to_additional_schools the requested-schools table updates asynchronously, so allow around 20 seconds before verifying.

Handshake auth is an email one-time code flow at app.joinhandshake.com/login. The mapped login action takes an email and signs in with the code, which you supply through Rindler's staged Connect form. This bypasses Google and Apple SSO for any account that also has email access, so your agent never has to drive a third-party identity popup.

The split is clean: browsing the public board (search_jobs, filter_jobs, view_job) works without a session, while the entire employer surface, from view_employer_home through applicants, talent, messaging, and school approvals, requires one. apply_to_job sits on the boundary: it starts from the public job detail page and hands off to the access/login screen.

Every step returns a resolved screen with structured results, so your agent reads records instead of scraping HTML. On the public side those screens are job_listing (the searchable, filterable board), job_detail (one opportunity), and apply_modal (the application handoff).

The employer side resolves to its own screen family: emp_dashboard for the home view, emp_jobs_list and emp_job_detail for postings, emp_job_applicants for a posting's candidates, emp_talent for the student directory, emp_conversations for the inbox (including the Sent folder), emp_job_post_wizard for the multi-step create-job flow (drive it interactively, not as one scripted shot), and emp_school_approvals plus emp_job_schools for campus approval status overall and per posting. The screen name in each response tells your agent exactly where it landed, which matters on a site where the public board and the employer workspace look nothing alike.