Business Automation Suites

Business Automation Suites: a Recruitment Desk and a Programming Desk

Business Automation Suites has two desks that exist as code: a Recruitment Desk for jobs, resumes, and calls, and a Programming Desk for seven engineering seats behind review gates. Some operations are gated by approval flags. Several items are under review before publication, and each one is marked in this page.

The problem

Teams that let AI agents contact candidates or change code need a bounded role, an approval step before any outside effect, and a record of what ran. Without those controls, an automated call or a merged change is hard to check afterward.

01 / 11

What are Business Automation Suites, and who are they for?

Business Automation Suites are two desks built as code. The Recruitment Desk handles jobs, resumes, and calls. The Programming Desk runs seven engineering seats behind review gates. They are for operators who run these workflows and want approval gates and recorded events before any outside action. Several items remain under review before publication.

At a glance

An operator is the person or team that runs a desk, holds its accounts, and sets its approval flags. The Recruitment Desk is a FastAPI service (a Python web framework) with a Next.js web app. It uses Grok models through the operator's own sign-in. This page does not describe it as a Grok Bot desk.

02 / 11

What problem does it solve?

At a glance

  • Runs job, resume, and call work in three lanes: Jobs, Resumes, and Calls.
  • Places an outbound call only after an operator sets an approval flag and the telephony checks pass.
  • Opens each outbound call with a disclosure that Grok transcribes it.
  • Keeps SEEK job listings as drafts until the posting settings are complete.
  • Gives each Programming Desk seat its own endpoint and refuses another seat's credential.
  • Requires a verification receipt for completion claims, and blocks a bot from approving its own work.

Recruiting and engineering work includes repeated steps: copying a job into a listing, rewriting resume wording, arranging a screening call, and checking a change before it merges. Both desks leave decisions with people, and section 5 shows where a person acts.

The core problem is trust. An automated call or a code change can be wrong, so the team needs to see what ran and who allowed it. Some checks exist only as instructions to an agent, and section 7 names them.

03 / 11

Why do existing approaches fall short?

This page does not compare other products. It lists the failure modes the code is written against.

  • Resumes that gain unsupported skills. A keyword is rewritten only when the source resume already says the same thing.
  • Calls with no disclosure or consent step. Each call opens with a disclosure and moves on only after a clear yes.
  • Outside effects with no approval record. A dial needs a true approval flag, and a destructive Programming Desk operation needs approval fields.
  • Completion claims with no evidence. A claim needs a receipt, and a claim citing a failing command is refused unless it sets an explicit flag.
  • Seats that reach each other's tools. A request to another seat's endpoint is refused with HTTP 403.

Each item is a control in code, not a promise of an outcome. Several controls are partial, and section 7 says which.

04 / 11

The approach

Both desks follow one rule: an outside effect passes a check in code, and the check leaves a record. A check that exists only as an instruction to an agent is labelled that way. The desks live in separate repositories, with separate records and status.

The Recruitment Desk keeps three lanes behind one API, and every outbound call uses the same approval flag, telephony checks, and opening disclosure. The Programming Desk keeps each seat in its own lane, with a prompt, a template, an endpoint, and a tool roster.

05 / 11

How does it work?

The flows below follow the code. Module paths are relative to each repository.

Recruitment Desk

Jobs. An operator-run endpoint supplies job records, fetched with one GET request. The desk maps each job into a SEEK listing draft (src/recruitment_swarm/job_bridge.py, src/recruitment_swarm/desk.py). The code does not log in to LinkedIn or crawl it, and it refuses LinkedIn and SEEK hosts as the source. Posting waits for the settings in src/recruitment_swarm/config.py.

Resumes. The keyword step (src/recruitment_swarm/resume_bridge.py, src/recruitment_swarm/keywords.py) rewrites a bullet only when it already holds a same-group alias, and lists unsupported keywords as missing. An engine named dspy runs the same check through DSPy, a Python library for prompt programs (src/recruitment_swarm/runtimes/dspy_phrase.py). That path writes no desk event.

Calls. The Calls lane (web/app/calls/page.tsx) sends a dial with the approval flag set. The server refuses unless the flag is true, the phone number is in E.164 form (the international phone format), and the three Twilio settings exist (src/recruitment_swarm/desk.py, src/recruitment_swarm/config.py). The call opens with this disclosure:

Hello, this is an automated initial interview from {company} about the {title} role. This call is transcribed by Grok so a recruiter can review it. It is not a decision by itself. You can say no or hang up now. Do you agree to continue and to this transcription?

The call moves to in progress only after a clear yes (src/recruitment_swarm/calling.py). Speech then goes to a realtime Grok voice session that transcribes with the model grok-transcribe (src/recruitment_swarm/runtimes/grok_voice.py). The fallback path sends the recording to a Grok speech-to-text endpoint with the model grok-voice-transcribe-2.0 (src/recruitment_swarm/clients.py). score_transcript in src/recruitment_swarm/calling.py counts keyword presence and gives one of five recommendations, each labelled an initial screen. [NEEDS CONFIRMATION: whether a recruiter must confirm each recommendation before action]

Programming Desk

Seats. Seven seats are defined: LEAD, SYSTEMS, WEB, ANDROID, IOS, INFRA, and QUALITY (services/desk-gateway/src/desk_gateway/config.py). Each has a prompt under prompts/, and scripts/generate-templates.py produces seven Grok Bot templates. The documented install is those templates and a bootstrap step (docs/upgrade-plan-desk-v2.md). This page does not describe a paste-the-URL install.

Gateway. services/desk-gateway/src/desk_gateway/server.py gives each seat its own MCP endpoint, where MCP (Model Context Protocol) is how agents call tools. A seat signs in through OAuth with PKCE, a code challenge that ties the sign-in to one client, and a consent page asks for its passphrase (services/desk-gateway/src/desk_gateway/oauth.py). Each tool call is checked against its input schema (schema.py), refused if its arguments look like a secret (redact.py), and stopped after 20 seconds. Each call writes an audit line that stores a digest of its arguments, not the arguments (audit.py).

Gates. ci/gates/run_all.py runs the repository gates. G-1 (ci/gates/check_ownership.py) checks one owner per changed file. G-2 (ci/gates/check_receipt.py) requires a receipt and a recorded approver who is not the bot. G-3 (ci/gates/check_secrets.py) runs in a pre-commit hook and in CI. G-5 and G-6 (ci/gates/check_rollback.py) require approval fields for destructive operations. G-4 is the contracts gate (ci/gates/check_contracts.py). A seventh gate, G-7 (ci/gates/check_desk_integrity.py), runs but is absent from the README table.

Across seats, gates, and gateway. A seat's tool calls pass the gateway checks, and its change then passes the gates in CI. The gates read the records attached to a change. For approvals, they check that a record exists, not who the approver is.

Example workflow (illustrative scenario)

This scenario is invented to show how the steps connect. It uses a hypothetical customer support lead role and does not describe a real candidate, call, or hire.

An operator imports one job for the role through the operator-run endpoint. The desk stores it as a SEEK draft, and nothing is posted because the posting settings are incomplete (src/recruitment_swarm/desk.py).

In the Resumes lane, the job's keywords are checked against a sample resume that already says customer service, so the phrasing can use the job's wording. A software platform the resume does not mention is listed as missing and is not added (src/recruitment_swarm/resume_bridge.py).

In the Calls lane, the operator reviews the planned call and sets the approval flag before any dial. The server dials only then, and only when the telephony settings and phone number pass. The call opens with the disclosure. Suppose the candidate says yes. The call moves to in progress, and the transcript is scored. The lane shows a recommendation of hold, labelled an initial screen. The operator then decides the next step.

06 / 11

What is the integration and security posture?

Integrations. The Recruitment Desk uses Twilio for calls and webhooks, Grok for speech and chat, SEEK for listings, and a Claude login for review and phrasing. Deepgram is a fallback voice provider when the Grok sign-in is missing. The API runs on the AgentOS library, whose JWT checks (a signed JSON format) stay off until a verification key is set. Telemetry is optional, and a failing sink does not fail a call.

Webhook checks. The Twilio request validator runs on the voice webhook, consent, and recording routes when a Twilio auth secret is set. Without a secret, the check is skipped, which is the local preview mode. [NEEDS CONFIRMATION: signature check on the voice stream route] The stream route runs no such check in the code reviewed.

Access. The desk routes have no authentication dependency in the code reviewed, and cross-origin requests are allowed from any origin. [NEEDS CONFIRMATION: who may send the approval flag on the dial route, and whether AgentOS authorization covers the desk routes]

Sign-ins and desktop. The Grok and Claude sign-ins are read from local stores (src/recruitment_swarm/runtimes/auth.py). The code reviewed does not write a sign-in value to a log or a response. The application has no LinkedIn login. A separate desktop automation configuration lists LinkedIn among the browser origins it may navigate and download from, under the operator's own signed-in profile (company/cua/cua-capabilities.yaml). [NEEDS CONFIRMATION: desktop automation configuration on LinkedIn origins]

Legal and consent. Operators are responsible for consent to calls and recordings, and for applicable law. Automated scoring of candidates may carry legal obligations in some jurisdictions. [NEEDS CONFIRMATION: legal review] No compliance, certification, or audit is claimed for either desk. [NEEDS CONFIRMATION: legal review] The compliance step before a call is an instruction to an agent, and no code checks it. [NEEDS CONFIRMATION: whether a compliance check is required in code before a call is placed]

Programming Desk checks. Inbound intake webhooks are checked with a keyed hash (HMAC-SHA256) over the raw body, with one secret per origin. Federation peer credentials are verified as signed JWTs, and each seat has its own passphrase.

Web3 boundary. Neither desk's seat or call operations use a blockchain or a wallet. Both desks run off-chain: records are local files and databases, and outside calls go only to the services named above or to upstreams the operator configures. Operator-held credentials cover the Recruitment Desk's Grok, Claude, Twilio, SEEK, LinkedIn, Deepgram, and AgentOS connections and database settings, and the Programming Desk's seat passphrases, intake and webhook secrets, federation peer keys, and upstream credentials. The ledger maps each statement here to its evidence.

Research modules. The Programming Desk gateway also holds 68 research modules in an experimental group (static count, services/desk-gateway/src/desk_gateway/). The seat tools and the intake route do not use them, and no seat path submits a chain transaction. The modules are reachable only through separate HTTP routes that this page does not describe. [NEEDS CONFIRMATION: owner decision on the research routes and their access control before publication] Some modules build records locally and set status labels, which do not show that a record reached any network. One module names post-quantum signatures, but its code uses keyed hashes under a secret. Three modules contain default secret values, which are not recorded here.

07 / 11

What is the current status?

Recruitment Desk

Implemented

  • Three lanes in the web app and API (web/app/calls/page.tsx, src/recruitment_swarm/api.py).
  • Approval check on the dial path and telephony check before any dial (src/recruitment_swarm/desk.py, src/recruitment_swarm/config.py).
  • Disclosure, consent gate, and transcript scoring (src/recruitment_swarm/calling.py).
  • Keyword check and resume keyword overlap (src/recruitment_swarm/resume_bridge.py).
  • Draft-first SEEK listings (src/recruitment_swarm/clients.py).
  • Claude review route with no shell or file tools (src/recruitment_swarm/runtimes/claude_review.py).

In progress

  • Live calls and transcription. The README reports a live voice session check that no test replays. [NEEDS CONFIRMATION: live call and live transcription run] (README.md, src/recruitment_swarm/runtimes/grok_voice.py)
  • SEEK posting. The repository has no SEEK API format, so the submission shape is unverified. [NEEDS CONFIRMATION: SEEK submission format] (src/recruitment_swarm/clients.py)
  • Auth coverage on desk routes. [NEEDS CONFIRMATION: access control on desk routes] (src/recruitment_swarm/api.py)
  • Stream signature check. [NEEDS CONFIRMATION: signature check on the voice stream route] (src/recruitment_swarm/api.py)
  • Empty stream address in the consent route. Reachability is inferred, and no test covers it. [NEEDS CONFIRMATION: reachability of an empty stream address in the consent route] (src/recruitment_swarm/api.py)
  • Pre-call compliance check, which exists only as an instruction. [NEEDS CONFIRMATION: whether a compliance check is required in code before a call is placed] (src/recruitment_swarm/desk.py)
  • Desktop automation on LinkedIn origins. [NEEDS CONFIRMATION: desktop automation configuration on LinkedIn origins] (company/cua/cua-capabilities.yaml)

Planned

  • Code enforcement of the approval rule for the agent team. The team's calling tool accepts the flag as an argument, and the rule is an instruction. [NEEDS CONFIRMATION: code enforcement of the approval rule for the agent team] (src/recruitment_swarm/swarm.py)
  • An event row for each import, phrase, call, and heartbeat, as the README describes. The DSPy phrase path writes none (src/recruitment_swarm/api.py).
  • A local install from the README line, which omits the DSPy and Claude Agent SDK packages that the Dockerfile installs (Dockerfile).

Maturity (static): 30 core source files (4,337 lines), 12 runtime files (1,443 lines), 15 web source files (1,031 lines), and 100 test functions in 12 test files (tests/). None was executed for this page.

Programming Desk

Implemented

  • Seven seat definitions, prompt files, and generated templates (services/desk-gateway/src/desk_gateway/config.py, grokbot/templates/).
  • One MCP endpoint per seat, OAuth consent with the seat passphrase, and HTTP 403 for a mismatched seat (services/desk-gateway/src/desk_gateway/server.py).
  • Schema checks, secret refusal, a deadline, and a redacted audit file (services/desk-gateway/src/desk_gateway/audit.py).
  • Gates G-1 to G-7, run by the gate runner (ci/gates/run_all.py).
  • Receipt rules: a receipt is required, self-approval is refused, and a claim citing a failing command is refused unless it sets an explicit flag (ci/gates/check_receipt.py).
  • Secret scan before commit and in CI (.pre-commit-config.yaml, .github/workflows/gates.yml).

In progress

  • Live Grok Bot connector run. None is recorded in the repository, so the gateway is not described as tested live through a Grok Bot card. [NEEDS CONFIRMATION: live Grok Bot connector run] (services/desk-gateway/src/desk_gateway/oauth.py)
  • Upstream adapters. Several run in a not-configured state in tests, and some have no test that reaches the adapter class (services/desk-gateway/src/desk_gateway/upstreams.py).
  • Template regeneration is run by hand, and no workflow checks the templates for drift (grokbot/README.md).

Planned

  • Whole-tree ownership. The ownership check examines files in each change, not every tracked path (ci/gates/check_ownership.py).
  • QUALITY approval. The receipt gate checks that an approver is recorded and is not the bot. It does not check that the approver holds the QUALITY seat. [NEEDS CONFIRMATION: whether QUALITY seat approval is enforced in code] (ci/gates/check_receipt.py)
  • Destructive-operation approval. The rollback gate checks that approval fields are present and counted. It does not check that the approver is a person, the event order, or the blast radius. [NEEDS CONFIRMATION: whether a person must approve destructive operations, enforced in code] (ci/gates/check_rollback.py)
  • Reviewer rule. The README says a reviewer may not fix the code it reviews, and no gate enforces it (ci/gates/).
  • Roadmap text describes publishing records to a public test network. The code reviewed submits nothing (.planning/ROADMAP.md).
  • Research modules sit outside the seat path and this page's scope. [NEEDS CONFIRMATION: owner decision on the research routes and their access control before publication] (services/desk-gateway/src/desk_gateway/server.py)
  • Paste-the-URL install is not described. The documented install is the templates and a bootstrap step (docs/upgrade-plan-desk-v2.md).

Maturity (static): 143 Python modules in the gateway package (56,206 lines), 639 gateway test functions in 100 files, and 136 gate test functions (ci/tests/). None was executed for this page. The README's own counts are not used.

08 / 11

What outcomes are intended?

  • Projected: Operators can trace each outside call, listing post, and seat tool call to a recorded event or audit line. Basis: the desk event rows and the gateway audit file in the code reviewed. The DSPy phrase path is a known exception.
  • Projected: Each candidate call opens with the disclosure and continues only after a clear yes. Basis: the disclosure text and the consent gate in calling.py and api.py.
  • Projected: Resume wording stays within what the source resume supports. Basis: the same-group alias rule in resume_bridge.py.
  • Projected: Engineering changes pass the ownership, receipt, and secret checks before merge. Basis: gates G-1 to G-3 and the CI workflow file.
  • Projected: The live voice path is checked against a real session before wider use. Basis: the README's live check, which no repository test reproduces.

09 / 11

Frequently asked questions

What do operators need to run each desk?

The Recruitment Desk needs a host for its API and web app, a Grok sign-in or API key, Twilio account settings for calls, and an operator-run job endpoint for imports. The Programming Desk needs the seven Team-only Grok Bot templates, the bootstrap step, and the gateway with a passphrase for each seat.

Can the Recruitment Desk place a call without an approval flag?

No. The dial route refuses unless the operator approval flag is true, and the flag is read from the request body. The team's calling tool also accepts the flag as an argument. [NEEDS CONFIRMATION: who may send the approval flag on the dial route, and whether AgentOS authorization covers the desk routes]

Does the Recruitment Desk score candidates?

Yes. It scores call transcripts by keyword presence, computes resume keyword overlap, and shows a recommendation labelled an initial screen. The code records no hire or reject outcome. [NEEDS CONFIRMATION: whether a recruiter must confirm each recommendation before action]

Does either desk use a blockchain or wallet?

Neither desk's seat or call operations use a blockchain or a wallet, and no seat path submits a chain transaction. Research modules in the Programming Desk gateway sit outside the seat path. [NEEDS CONFIRMATION: owner decision on the research routes and their access control before publication]

10 / 11

What is the next step?

Request a technical briefing through the site's contact page. Ask for the approval-flag design, the gate list, and the open items in this page, in writing. This page does not cover commercial terms.

11 / 11

Source notes

Paths are relative to each repository (swcstudiospace/recruitment-swarm and swcstudiospace/programming-desk) unless noted.

swcstudiospace/recruitment-swarm

  • README.md
  • Dockerfile
  • src/recruitment_swarm/api.py
  • src/recruitment_swarm/desk.py
  • src/recruitment_swarm/swarm.py
  • src/recruitment_swarm/calling.py
  • src/recruitment_swarm/clients.py
  • src/recruitment_swarm/config.py
  • src/recruitment_swarm/job_bridge.py
  • src/recruitment_swarm/keywords.py
  • src/recruitment_swarm/resume_bridge.py
  • src/recruitment_swarm/runtimes/auth.py
  • src/recruitment_swarm/runtimes/claude_review.py
  • src/recruitment_swarm/runtimes/dspy_phrase.py
  • src/recruitment_swarm/runtimes/grok_voice.py
  • web/app/jobs/page.tsx
  • web/app/resumes/page.tsx
  • web/app/calls/page.tsx
  • company/cua/cua-capabilities.yaml
  • tests/

swcstudiospace/programming-desk

  • README.md
  • prompts/
  • scripts/generate-templates.py
  • grokbot/templates/
  • grokbot/README.md
  • grokbot/avatars/
  • docs/upgrade-plan-desk-v2.md
  • .planning/ROADMAP.md
  • services/desk-gateway/src/desk_gateway/config.py
  • services/desk-gateway/src/desk_gateway/server.py
  • services/desk-gateway/src/desk_gateway/oauth.py
  • services/desk-gateway/src/desk_gateway/schema.py
  • services/desk-gateway/src/desk_gateway/redact.py
  • services/desk-gateway/src/desk_gateway/audit.py
  • services/desk-gateway/src/desk_gateway/upstreams.py
  • services/desk-gateway/src/desk_gateway/ (research module group)
  • services/desk-gateway/tests/
  • ci/gates/
  • ci/gates/run_all.py
  • ci/gates/check_ownership.py
  • ci/gates/check_receipt.py
  • ci/gates/check_secrets.py
  • ci/gates/check_contracts.py
  • ci/gates/check_rollback.py
  • ci/gates/check_desk_integrity.py
  • ci/hooks/pre-commit
  • ci/tests/
  • .pre-commit-config.yaml
  • .github/workflows/gates.yml

Questions

Frequently asked questions

01

What do operators need to run each desk?

The Recruitment Desk needs a host for its API and web app, a Grok sign-in or API key, Twilio account settings for calls, and an operator-run job endpoint for imports. The Programming Desk needs the seven Team-only Grok Bot templates, the bootstrap step, and the gateway with a passphrase for each seat.

02

Does the Recruitment Desk score candidates?

Yes. It scores call transcripts by keyword presence, computes resume keyword overlap, and shows a recommendation labelled an initial screen. The code records no hire or reject outcome. [NEEDS CONFIRMATION: whether a recruiter must confirm each recommendation before action]

03

Does either desk use a blockchain or wallet?

Neither desk's seat or call operations use a blockchain or a wallet, and no seat path submits a chain transaction. Research modules in the Programming Desk gateway sit outside the seat path. [NEEDS CONFIRMATION: owner decision on the research routes and their access control before publication]

Sources

Sources

  • Recruitment Desk README swcstudiospace/recruitment-swarm, README.md
  • Desk API service swcstudiospace/recruitment-swarm, src/recruitment_swarm/api.py
  • Desk logic swcstudiospace/recruitment-swarm, src/recruitment_swarm/desk.py
  • Calling and disclosure swcstudiospace/recruitment-swarm, src/recruitment_swarm/calling.py
  • Resume keyword checks swcstudiospace/recruitment-swarm, src/recruitment_swarm/resume_bridge.py
  • Calls lane swcstudiospace/recruitment-swarm, web/app/calls/page.tsx
  • Desktop automation configuration swcstudiospace/recruitment-swarm, company/cua/cua-capabilities.yaml
  • Programming Desk README swcstudiospace/programming-desk, README.md
  • Gateway server swcstudiospace/programming-desk, services/desk-gateway/src/desk_gateway/server.py
  • Seat sign-in and consent swcstudiospace/programming-desk, services/desk-gateway/src/desk_gateway/oauth.py
  • Gate runner swcstudiospace/programming-desk, ci/gates/run_all.py
  • Receipt gate swcstudiospace/programming-desk, ci/gates/check_receipt.py
  • Ownership gate swcstudiospace/programming-desk, ci/gates/check_ownership.py
  • Rollback gate swcstudiospace/programming-desk, ci/gates/check_rollback.py
  • Seat configuration swcstudiospace/programming-desk, services/desk-gateway/src/desk_gateway/config.py
  • Install plan swcstudiospace/programming-desk, docs/upgrade-plan-desk-v2.md