# From personal worker to business worker (/claude-and-chatgpt-2/architecture/from-personal-worker-to-business-worker) --- type: Document title: "From personal worker to business worker" description: "How to keep Claude as the engine and build a business layer around it. It covers the MCP server, Better Auth, Postgres on Neon, Claude Tag and the four runtime options." status: stable order: 0.491 ksor: owner: team:panaversity audience: [ public ] approval: by: process:panaversity at: 2026-11-09T20:42:36Z chapter: "F00A" part: Front expert_status: required concepts: [ "Business worker" ] last_verified: 2026-11-09 sources: - id: neon-better-auth title: "Managed Better Auth is now an OAuth provider, with MCP support (Neon, November 2, 2026, verified 2026-11-09)" resource: https://neon.com/blog/managed-better-auth-oauth-provider-mcp - id: better-auth-mcp title: "Better Auth MCP plugin (Better Auth, verified 2026-11-09)" resource: https://better-auth.com/docs/plugins/mcp - id: managed-agents title: "Claude Managed Agents overview (Anthropic, verified 2026-11-09)" resource: https://platform.claude.com/docs/en/managed-agents/overview - id: cloud-scheduled-tasks title: "Automate work with scheduled tasks (Anthropic, verified 2026-11-09)" resource: https://code.claude.com/docs/en/routines - id: claude-projects title: "Let Claude coordinate ongoing work with Projects (Anthropic, verified 2026-11-09)" resource: https://code.claude.com/docs/en/claude-projects - id: claude-tag-overview title: "Work with Claude Tag (Anthropic, verified 2026-11-09)" resource: https://claude.com/docs/claude-tag/overview - id: claude-tag-identity title: "How agent identity works, Claude Tag (Anthropic, verified 2026-11-09)" resource: https://claude.com/docs/claude-tag/concepts/agent-identity - id: claude-tag-security title: "Security and data handling, Claude Tag (Anthropic, verified 2026-11-09)" resource: https://claude.com/docs/claude-tag/concepts/security-and-data generated: at: 2026-11-09T20:42:36Z by: process:panaversity trust_tier: unverified build_id: sha256:46fd53c5d7ab1c14f6347908d45c9fdaecda4d914439923ee878bdcecd57803e dirty: true ksor_version: 0.0.60 --- ### Keep the engine, build the layer Keep Claude as the engine. Build a business layer around it. When the stakes rise, move the runtime from the consumer app to the API. Here the business layer is an MCP server you own, secured by Better Auth, with records in Postgres on Neon. **MCP** is the open standard connectors use. **Better Auth** is a sign-in system. **Neon** hosts **Postgres** databases. This is one reference design, not a definition. The runtime can be the Claude app, Claude Tag, Claude Managed Agents or the Claude Agent SDK. **[Inferred]** MCP keeps the business layer largely portable across them. Your rules, records and enforcement stay the same. Credentials, connection settings and approval requests need work for each runtime. ![Four runtimes, one business layer. The Claude app (acts as you), Claude Tag (its own service accounts), Claude Managed Agents (hosted, in beta) and the Claude Agent SDK (self-hosted) all reach your MCP server. The server uses Better Auth for worker identity, checks approvals and allows one payment per intent. Below it sit Postgres on Neon, an approval page and business systems. A band says Code tab and Claude Tag sessions can run on self-hosted runners, though Claude Tag cannot use admin connectors there.](img/four-runtimes-one-business-layer.png) **[Inferred]** A [project](projects-coordination-on-top-of-sessions.md) strengthens one person's worker, but it is personal in scope.[^claude-projects] ### The business layer: what to build Better Auth on Neon handles sign-in and gives each worker its own keys. Postgres holds the records. Your MCP server enforces the rules. Token details are in [Appendix: business-layer details](appendix-business-layer-details.md). | Requirement | What to build | Basis | | --- | --- | --- | | Own identity | A dedicated account or OAuth client (a registered app identity that can be given keys) for each worker, with narrow scopes. For example, it may propose payments but may not approve them | The OAuth tooling is vendor-documented.[^neon-better-auth],[^better-auth-mcp] One client per worker is the inferred design | | Durable state | Tables for work items, approvals, payment intents and an audit log, using transactions and unique constraints | Vendor-documented. The design is inferred | | Enforced authority | MCP tools that check the approval record and the token's scopes before acting. No caller gets raw SQL (direct database commands). The reconciliation worker gets only tools such as `record_status` and `propose_payment`. `execute_payment` belongs to a separate caller: the payment officer, or a payment worker with only that scope | The design is inferred | | Human approval | A small approval page where a named person signs in and approves. The decision is written to Postgres. The review artifact only displays rows | The design is inferred | | Audit and operations | Every tool call is logged with who, what, when, the result and the approval ID. Monitoring and cost budgets for each worker | The event history is vendor-documented[^managed-agents] | The [worked example](worked-example-brightlines-payment-run-as-a-business-ai-worker.md) explains transactions, payment intents and their states. ### Identity: who is acting, and on whose behalf **[Inferred]** The system must tell four parties apart and record all of them on every action. A **tenant** is the organization a record belongs to. | Party | What it is | Rule the server enforces | | --- | --- | --- | | Worker principal | The worker's own OAuth client or account, limited to the tools its role needs | It can propose actions. It can never approve its own proposals | | Human approver | A named person who signs in through Better Auth | Approvals carry that person's identity. They are bound to one exact payment and expire, as in the [worked example](worked-example-brightlines-payment-run-as-a-business-ai-worker.md). The worker can never act as the approver. The approver is never the payment caller for the same intent | | Human sponsor | The person or team accountable for the worker | Owns the worker's scopes and handles problems. The sponsor should not also approve its payments (separation of duties) | | Organization (tenant) | The business the worker acts for | Every record and token carries the tenant, so a worker cannot reach another tenant's data | Every audit entry names the worker, the tenant, the approver and the approval ID. So you can always answer: who did what, under whose authority? Key handling is in the [appendix](appendix-business-layer-details.md#worker-identity-in-detail). ### The runtime: four options | Runtime | What Anthropic runs | Identity and control | Use when | | --- | --- | --- | --- | | Claude app (conversations, tasks and scheduled tasks) | Everything: the harness, the sandbox and the schedules | Runs as you. See the limits in [Scheduled tasks](scheduled-tasks.md) | Personal and team workers, and prototypes | | Claude Tag (Slack, Team and Enterprise) | The harness and a sandbox for each Slack thread, in organization-level environments | Its own service accounts, set up by an Owner. Not a person. See below | Team workers that several people steer in a channel | | Claude Managed Agents (API) | A hosted harness and cloud sandbox, or a sandbox you host. You define an agent (model, prompt, tools, MCP servers, skills) and start sessions from your backend | Your organization's API account. Sessions keep their state and their event history on the server. Scheduled execution is a listed use. In beta, with the compliance limits listed in the [appendix](appendix-business-layer-details.md#runtime-limits) | Production workers you do not want to host | | Claude Agent SDK | Only the model. You run the harness | Fully yours: hosting, logging and compliance | Full control or strict compliance | **Basis:** vendor-documented.[^managed-agents],[^cloud-scheduled-tasks] ### Claude Tag: a team worker with its own accounts **[Vendor-documented]** Claude Tag is Anthropic's answer to a worker that does not appear as you. It puts Claude in your team's Slack channels, in public beta on Team and Enterprise plans. Anyone in a channel can hand it work. There, "Claude acts with its own service accounts, rather than as a specific user." Actions appear in each tool's audit log under those accounts. Credentials stay outside the sandbox, "so the model and the sandbox are not given the key." It is not available with Zero Data Retention, customer-managed encryption or the HIPAA configuration.[^claude-tag-overview],[^claude-tag-identity],[^claude-tag-security] In a self-hosted environment, Claude Tag cannot use the connectors an admin adds.[^claude-tag-security] **[Vendor-documented]** One warning matters for money. A connector's credential "is shared by everyone in the channels where it applies," so anyone in those channels can ask Claude to act with it.[^claude-tag-security] **[Inferred]** So Claude Tag covers the "own identity" row and part of "audit". Its pages do not describe a business record or an approval check before a payment. For Brightline, the connector still checks the approval, whoever asked in Slack. ### Two paths 1. **Personal and team workers.** Stay in the Claude app, connected to your MCP server. You get real records and enforced approvals at once. One limit: a claude.ai connector is signed in by a person, so the worker has its own identity only if a dedicated worker account signs it in. For team work in Slack, [Claude Tag](#claude-tag-a-team-worker-with-its-own-accounts) acts under its own service accounts. 2. **Business workers that handle money, customers or records.** Move the runtime to Managed Agents, or to the Agent SDK for full control. Your backend starts sessions under a service identity and keeps its own logs. The MCP server, the database and the approval page carry over. The [appendix](appendix-business-layer-details.md#what-is-built-in-and-what-you-write) lists what each part gives you and what you write. Build the business layer first. It holds everything that must be trustworthy: identity, records, approvals and audit. Then changing the runtime is an integration task. Codex also supports MCP servers, so the same layer can serve OpenAI workers too. [^neon-better-auth]: As verified on November 9, 2026. Managed Better Auth is now an OAuth provider, with MCP support, Neon. [^better-auth-mcp]: Better Auth MCP plugin, Better Auth. [^managed-agents]: As verified on November 9, 2026. The overview covers the hosted harness and sandbox, sessions, events and beta status. Claude Managed Agents overview, Anthropic. [^cloud-scheduled-tasks]: Automate work with scheduled tasks, Anthropic. [^claude-projects]: As verified on November 9, 2026. Let Claude coordinate ongoing work with Projects, Anthropic. [^claude-tag-overview]: As verified on November 9, 2026. Claude Tag was in public beta. Work with Claude Tag, Anthropic. [^claude-tag-identity]: As verified on November 9, 2026. How agent identity works, Claude Tag docs, Anthropic. [^claude-tag-security]: As verified on November 9, 2026. Security and data handling, Claude Tag docs, Anthropic.