SysEngineering

cos_lab: Adam’s chief-of-staff prototype

Adam’s personal chief of staff, built the way SCSP plans to build one for everyone: Claude (or ChatGPT) connected through one remote MCP connector with Google sign-in, per-person tools, permission checks and a record of use. The connector reads Adam’s own GitHub, Jira and Confluence, Google Calendar and Gmail, and Okta, all read-only.

It is the SCSP connector in miniature: prove each hard part on one person before SCSP depends on it. Design reference: Confluence IPO → 3.M.3 SCSP Architecture (Proposal). Tracked in Jira ITPROJ-1421 (under the SCSP epic ITPROJ-1401).


Code	this folder, `integrations/scsp_ai_initiative/cos_lab` in Hillspire/SysEngineering
Google Cloud	project `adam-cos-lab`, schmidtentity.com organization
Jira	ITPROJ-1421
Current state and next steps	HANDOFF.md
The connector’s security reviews, every finding and its fix	REVIEWS.md
SCSP context	the parent folder: ../HANDOFF.md, ../CLAUDE.md

How it fits together

Claude Code / claude.ai ──OAuth: our consent page, then Google sign-in──▶ connector  /mcp
                                                       │  who is asking: from the token, never a tool argument
                                                       │  policy: which tools this person may use
                                                       │  record of use: one JSON line per event, never content
                                                       ▼
                                   GitHub · Jira/Confluence · Calendar · Gmail · Okta   (read-only)

Two shapes are worth keeping apart, because SCSP will use both:

Their app runs the agent (what this folder builds first). Claude runs the loop and calls our connector. We own the tools and the permission checks, not the model.
We run the agent (lab/core/loop.py, lab/cli.py). Our own hand-written loop calls Claude on Vertex. This is the shape SCSP’s leadership work agents will take.

Where it stands

Step	What	State
1	GCP project, Jira ticket, code	Done 2026-10-13; code moved into SysEngineering 2026-10-15
2	Remote connector: Cloud Run, OAuth with dynamic client registration (Gwen’s pattern), Google sign-in, `whoami`, record of use, GitHub tools; connected from Claude Code	Built locally (`lab/connector/`) and through three adversarial security reviews (2026-10-15), on branch `feat/cos-lab-connector`; the PR, the live run and the deploy are next
3	Calendar and Gmail through Adam’s own consent at sign-in
4	Jira and Confluence through a read-only scoped token
5	Okta through a read-only OAuth service app
6	Permissions in miniature: a policy file, two identities (hillspire.com, schmidtentity.com) with different tools
7	claude.ai custom connector, once Hillspire’s Claude organization allows it
8	A work agent: Adam’s Friday report (a WAR prototype)

Already built and tested (164 tests): read-only GitHub, Jira and Google tools in lab/tools/, the hand-written agent loop with a step-by-step trace, a local MCP server, and the remote connector in lab/connector/: its own OAuth server with a consent page and Google sign-in, sign-in sessions, tools per person and a record of use. The suite runs on every PR that touches this folder (workflow “SCSP CoS Lab Tests”).

The connector, module by module:

Module	Job
`oauth.py`	The authorization server Claude talks to: clients, codes, tokens, sessions. Its docstring walks the whole sign-in journey.
`signin.py`	The pages the person sees: our consent page, then back from Google
`google_oidc.py`	Google’s side: the sign-in request, and checking Google’s answer
`signer.py`	HMAC-signed values (client IDs, sign-in state, tokens); `python -m lab.connector.signer` makes the key
`store.py`	What has to be remembered: one-time codes, one-time claims, sign-in sessions
`app.py`	The MCP server: who may use which tool, running it, and the SDK routes it wraps
`audit.py`	The record of use: one JSON line per event, never content
`__main__.py`	Settings, secrets from Secret Manager, logging, the web server

The rules it keeps are in CLAUDE.md, “The connector”, each pinned by a test.

On a new machine

From an up-to-date sysengscripts checkout. Until the connector PR merges, that means the branch feat/cos-lab-connector, not main (see HANDOFF.md, “Resuming on another machine”):

cd integrations/scsp_ai_initiative/cos_lab
python3.13 -m venv .venv                 # Windows: py -3.13 -m venv .venv
# Windows: .venv\Scripts\python   ·   macOS: .venv/bin/python
<venv python> -m pip install -r requirements.txt
<venv python> -m pytest -q -p no:cacheprovider
gcloud auth login && gcloud auth application-default login

To run the connector itself, see HANDOFF.md, “Run it locally”.

Secrets never live on disk. GitHub borrows gh auth token; everything else comes from 1Password through op run --env-file=secrets.env.tpl -- ... locally, or from Secret Manager in adam-cos-lab once deployed.

Ground rules (test-enforced where they can be)

Read-only. HTTP connectors have one GET helper; Google scopes end in .readonly.
Identity comes from sign-in. No tool takes a user, email or account.
Tool output is untrusted. Results are framed as data; the model is told never to follow them.
Credentials only in adam-cos-lab’s Secret Manager, never in gw-admin-assistant, where others can read every secret.
Company accounts only. Work data never goes to a consumer AI plan.
Sign-in as the MCP spec requires of a connector that signs people in with one fixed Google client: our own consent page first, and only the approving browser finishes, once.
Every step is recorded, never its content, including every refusal.