Skip to main content

Foreman

A construction field command center where an agent can schedule, notify, and file work — without the app ever storing Google, Slack, or Procore credentials.

View GitHub repo
  • Auth0 Token Vault
  • Semantic Kernel
  • .NET 8
  • PWA
Foreman command center showing Token Vault identity and a planned Calendar plus Slack action

The problem

Agents that can act are useful. Agents that hold standing API keys are a liability. Construction teams already live in Calendar, Slack, and Procore. Wiring those tools the usual way means storing third-party tokens in your app, or giving an agent a forever secret.

Foreman was built for the Authorized to Act hackathon. The bet: one Auth0 login, local reasoning, and every downstream action exchanged through Auth0 Token Vault as a short-lived, user-scoped token.

What it does

  • Field workers sign in once with Auth0 and send voice, photo, or text commands from an installable PWA.
  • Semantic Kernel plans which tools to run. Calendar and Procore calls use Token Vault delegated tokens. Slack uses a scoped bot token.
  • The same action endpoint accepts an OpenClaw webhook, so a restricted agent can trigger work without implementing OAuth itself.
  • Phrases like overtime, budget, or change order return a 401 step-up challenge. The client re-auths before the action runs.
Foreman mobile PWA with a field command and last-action audit

Why this pattern matters

This is the “authorized to act” problem in concrete form. Reasoning can stay local. Actions that change someone else’s calendar, chat, or project system go through identity, a short TTL, and an audit row. That is the same control plane you want before an agent can refund, deploy, or move money.

I wrote up how this maps onto an enterprise agentic delivery lifecycle in the ADLC reference. RelAI is the other half of the story: who is this agent?