From personal worker to business worker

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.

[Inferred] A project strengthens one person's worker, but it is personal in scope.¹

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.

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.²,³ 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⁴

The worked example 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. 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.

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	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	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.⁴,⁵

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.⁶,⁷,⁸ In a self-hosted environment, Claude Tag cannot use the connectors an admin adds.⁸

[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.⁸ [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

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 acts under its own service accounts.
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 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.