Cloudflare
Workers, Agents SDK, Queues, Workflows, D1 and R2 use the available credit and remove server operations.
Architecture decision • July 2026
Recommendation
One shared runtime.
One agent identity per workspace.
Run the system on Cloudflare with durable memory per Google Chat conversation. Give each of the 5–10 Plane workspaces its own named Chat app, but route all of them through one codebase and one Plane MCP service.
The answer first
What will be built
A private, organization-only Chat agent layer that makes Plane usable without opening Plane for normal daily work.
People
Google Chat identities
Zikra · Z360 · Summit · MillOS · 5–10 total
Verified event
Shared runtime
Agent gateway
Verify · route · queue · reply
Conversation agent
Durable transcript · summary · jobs
Scoped tools
Authoritative systems
Plane MCPProjects · members · tickets
Workspace APIsCalendar · Drive only
Search & knowledgeWeb · approved company corpus
Private artifactsStandups · audits · dashboards
AI SDK ToolLoopAgent
A small open-source tool loop inside the Cloudflare agent. No deep-agent harness or subagents.
Workers AI gpt-oss-20b
Open-weight, function-calling model. The 120B version is a tested replacement only if the evaluation proves it necessary.
Conversation-scoped SQL
One durable database per DM or Space thread. DMs never leak into shared Space memory.
In practice
A Z360 employee messages Z360 Agent in Chat. The message cannot select Zikra or another Plane workspace: the agent identity fixes the workspace before the AI runs. The system remembers that DM or Space thread, checks the person’s real Plane permissions, calls the allowed Plane tools, and posts the answer or report back in the same place.
Phase 1
Requirements documentation and high-level architecture
Every stated requirement is mapped to an explicit decision. “Done” means every row is implemented and tested.
22requirements captured
5–10workspace agents supported
0stateless conversations
1shared codebase
| ID | Requirement | Architectural decision | Acceptance evidence |
|---|---|---|---|
| R01 | Connect multiple Plane workspaces | One installation record and Chat identity per workspace; one shared runtime. | 10 configured agents route only to their bound workspace. |
| R02 | Workspace admin creates and connects an agent | Admin setup page captures Plane slug, prompt, tools and data sources; it generates the Google registration checklist. | Admin configures a pilot without an engineer editing code. |
| R03 | Available organization-wide in DMs and Spaces | Private Workspace Marketplace listing; user or Google Group installation; Space mentions and direct messages. | Pilot users can find, DM and add the app to an allowed Space. |
| R04 | Plane access through MCP | One pinned, HTTPS Plane MCP service per Plane instance; workspace slug fixed by installation and personal token fixed by verified user. | Admin, member and guest calls match native Plane permissions. |
| R05 | Google Calendar access | Stable Calendar REST API, read-only, using domain-wide delegation to impersonate the verified Chat user. | Agent reads only events the requester can read. |
| R06 | Google Drive access | Stable Drive REST API, read-only, with the requester’s Google permissions. | A permitted file is found; a forbidden file is not returned. |
| R07 | Web search | Cloudflare AI Gateway web-search adapter, invoked only for current external information. | Results include source URLs; cost and credit coverage are measured. |
| R08 | Internal company data | Approved, workspace-wide Drive corpus synced to private R2 and one workspace-scoped AI Search index; private files stay live-only. | Results never cross workspace or source access boundaries. |
| R09 | Remember conversations | Durable Object SQLite stores turns, summary, active objective, decisions, tool receipts and artifacts. | Context survives restarts and later conversations continue correctly. |
| R10 | Prepare tickets | Agent drafts the ticket in the conversation, resolves current Plane IDs, then creates it on the user’s instruction. | Created ticket matches title, description, project and assignee. |
| R11 | Prepare standups | Scheduled or on-demand aggregation of cycle work, comments, activities and Calendar context. | Report links every statement to live source data. |
| R12 | Audit team performance | Compute evidence-based delivery summaries outside Plane from assignments, activity, dates and completion; manager-only authorization. | Every judgment has visible source items and date range. |
| R13 | Build dashboards | Aggregate Plane MCP data, render an HTML dashboard, store it in private R2 and post an authenticated link. | Displayed totals reconcile with the same Plane query. |
| R14 | Answer questions | Tool loop reads live Plane, Calendar, Drive and approved knowledge; memory is context, not current truth. | Answers cite the items or files used. |
| R15 | Update tickets | Use personal-token MCP calls; write an immutable action receipt and read the item back. | Chat receipt and Plane result match. |
| R16 | Publish real-time artifacts | On-demand and scheduled Workflows render to private R2; authenticated viewer returns the current artifact. | Chat link opens for an authorized user and fails closed for others. |
| R17 | Know projects and team members | Refresh project/member/state catalog from Plane MCP, cache briefly in D1, and re-read before writes. | New members/projects appear without redeploying. |
| R18 | Separate configurable agent per workspace | Distinct name, icon, Google project, endpoint audience, prompt, tool set and memory namespace. | Z360 and Zikra agents can coexist in the same Space without crossing data. |
| R19 | Simple administration | One shared deployment; guided per-workspace registration; no per-workspace runtime. | Adding workspace 6 is configuration, not a new code deployment. |
| R20 | No Gmail access | No Gmail scope, connector, MCP tool or ingestion path exists. | OAuth and domain delegation scope inventory contains no mail scope. |
| R21 | Use only specified credit pools and free frameworks | Cloudflare runtime/inference, AWS for existing Plane/MCP, Fireworks only for evaluated fallback; Agents SDK and AI SDK are open source. | Account billing shows only approved runtime/inference providers. |
| R22 | Manage requests from many users and agents | Verify → deduplicate → queue → serialize per conversation → run tools → async reply. | Concurrent threads run in parallel; messages in one thread stay ordered. |
Documented platform boundary
A Plane workspace admin cannot publish a Google Chat identity organization-wide unless that person also has the required Google Cloud and Google Workspace roles. The site can make setup guided, but Google documents this as a console and private Marketplace workflow; there is no verified API that fully creates and publishes these identities.
Google Chat configuration ↗
Phase 2
Stack research and evaluation
Documented capabilities first; architectural judgment second. The final recommendation follows only after every named option is addressed here.
DocumentedVendor or project documentation says this directly.DecisionOur conclusion for this Plane–Google Chat system.
01Required foundation
Google Chat authentication and organization deployment
Documented Every Chat app needs its own Google Cloud project. Google signs HTTPS interaction events; a non-Google backend verifies the OIDC token’s signature, issuer, expiry and exact URL audience. Synchronous replies have a 30-second deadline. Private Marketplace apps stay inside the organization.
Decision Create 5–10 projects and visible identities, all targeting unique paths on one Worker. Acknowledge in about two seconds, queue the work, and post the result asynchronously as the app using chat.bot. Publish privately; install by user or relevant Google Group so employees are not given ten unwanted DMs.
02Compatibility spike first
Plane MCP on Community Edition
Documented Plane’s MCP supports Streamable HTTP and identifies a workspace by an x-workspace-slug header. The current setup page and the released v0.2.10 integration test disagree on whether the inbound personal token is x-api-key or Bearer authorization. Community 1.3.1 source does not prove the documented OAuth application UI or routes exist.
Decision Pin v0.2.10, run one shared MCP service per Plane base URL, and test Bearer token + fixed workspace slug first because that is what the release test executes. Each person connects a Plane personal token once; the agent then preserves Plane’s own permissions and attribution. If the stock process requires absent OAuth settings, expose only its personal-token HTTP application through a minimal entry point. Do not invent OAuth credentials.
Alternative rejected: a shared workspace or admin token would remove the one-time user connection, but it would also bypass native role enforcement and collapse every Plane write onto a bot identity. That is not an acceptable default.
03Do not choose
AWS Bedrock Agents
Documented Agents Classic manages orchestration, API action groups, knowledge bases, memory and traces. AWS now says new customers cannot start after 30 July 2026 and directs them to AgentCore.
Decision Reject Classic on lifecycle alone. AgentCore is the credible AWS alternative, with runtime, memory, identity and MCP, but it spreads this design across more AWS configuration than Cloudflare. Keep it as plan B, not v1.
04Too much harness
LangChain Deep Agents
Documented Deep Agents adds task planning, subagents, a virtual filesystem, long-term memory, summarization, MCP, code execution and human intervention on LangGraph.
Decision Reject for v1. Ticket and report operations need a short tool loop, not subagents, a filesystem and a Python/LangGraph operating surface. It would add more deployment and more ways to fail without removing the Google or Plane work.
05Use as library
Vercel AI SDK agent API
Documented AI SDK’s ToolLoopAgent manages the model, tools, context and loop; AI SDK Core can create an MCP client with custom headers.
Decision Use it inside Cloudflare only as the model/tool adapter. It is not the state store, request router or host. There is no separate stable open-source “Vercel Agent SDK” needed here; the applicable surface is the Agent API inside AI SDK.
06Not needed
Vercel Workflow SDK
Documented Workflow SDK provides durable, resumable TypeScript functions, retries, scheduling and self-hosting.
Decision Do not add it. Cloudflare already supplies Queues, Durable Objects and Workflows inside the selected credit and runtime. A second durability system would duplicate state and observability.
07Revisit later
Vercel Chat SDK
Documented Chat SDK abstracts many chat platforms and has a Google Chat adapter with DMs, mentions, cards and post/edit streaming. The official adapter catalog marks every platform adapter, including Google Chat, Beta.
Decision Use Google’s API directly in v1. One channel does not justify another abstraction, and exact Google authentication matters here. Revisit only if Slack or Teams becomes a real requirement.
08Preview
Vercel Eve
Documented Eve is a new open-source durable-agent system with sessions, sandboxes, approvals, scheduling, MCP/HTTP connections, channels and evaluations. It entered public preview in June 2026.
Decision Reject for v1. Its sandbox and subagent scope is unnecessary, Google Chat is not the proven primary channel, and current non-Vercel deployment evidence is not mature enough for a core operating system.
09Best fit
Cloudflare agentic infrastructure
Documented Agents SDK gives each agent durable identity, local SQL, routing, schedules, queues, MCP and model-provider flexibility. Durable Objects serialize access and persist SQLite state across restarts. R2 is writable from Workers.
Decision Make this the runtime and primary framework. It satisfies memory, multi-tenant routing, background work, artifacts and open-model inference in one operational surface covered by the available credit.
10Wrong-sized runtime
Aegra — not “Igra AEGRA”
Documented The verified project is Aegra: an Apache-2.0, self-hosted LangGraph deployment runtime with FastAPI, PostgreSQL persistence, Redis workers, schedules, streaming and custom authentication.
Decision Reject. It is a good choice for teams already committed to LangGraph, but here it adds Python, Postgres and Redis while still requiring the entire Chat bridge and Plane integration.
11Patterns borrowed
Claude Tag and Slack agent patterns
Borrow from Claude Tag
- A visible agent identity shared by a channel or workspace.
- Admin-chosen tools, repositories and memory boundaries.
- Long-running tasks post progress and return to the originating thread.
- Shared channel memory is separate from private DM context.
Borrow from Slack agents
- Acknowledge quickly; process after the platform deadline.
- Use the thread ID as the long-lived context key.
- Store structured summaries instead of replaying whole history.
- Use globally unique event IDs and idempotent output.
Decision Give each Plane workspace one agent identity. In a Space, the thread is the shared conversation. In a DM, memory is private. Do not add ambient channel monitoring or general autonomous standing tasks; neither is required.
Comparative fit
This is an architecture assessment, not a vendor benchmark.
| Option | Chat fit | Durable memory | MCP | Operations | Credit fit | Verdict |
|---|---|---|---|---|---|---|
| Cloudflare Agents + direct Chat API | Exact | Built-in SQL | Native + AI SDK | Lowest | $10k | Choose |
| AWS AgentCore | Custom bridge | Managed | Native | Medium | $60k | Plan B |
| AI SDK + Workflow + Chat SDK | Google adapter Beta | Bring storage | Yes | Medium | No Vercel credit | Use AI SDK only |
| Deep Agents + Aegra | Custom bridge | Postgres/LangGraph | Yes | Highest | AWS possible | Reject |
| Bedrock Agents Classic | Custom bridge | Managed, ≤365 days | Action groups | Medium | $60k | Reject lifecycle |
| Eve | Channel story immature | Durable sessions | Yes | Unproven here | No Vercel credit | Reject preview |
State choice
Choose: one Durable Object SQLite database per conversation, plus D1 for shared configuration.
Not chosen: one global Postgres database. It can work, but it adds an always-on service and concurrency code that Durable Objects already solve.
Routing choice
Choose: endpoint audience → installation → conversation key. The model never chooses the workspace.
Not chosen: one generic bot that asks “which workspace?” That makes data boundaries prompt-dependent.
Harness choice
Choose: Cloudflare Agent + AI SDK ToolLoopAgent, with a small set of tools and a persisted conversation summary.
Not chosen: deep-agent planning and subagents. The required jobs are bounded integrations, not open-ended research programs.
Phase 3
Final architecture recommendation
The smallest end-to-end design that meets the requirements without becoming a platform project.
Visible channelNative Google Chat API
One app identity per Plane workspace; DMs and Spaces.
Runtime & frameworkCloudflare Workers + Agents SDK
Shared ingress, durable agent instances, routing and scheduling.
Tool loopAI SDK ToolLoopAgent
Open-source model and MCP adapter; no second state system.
InferenceWorkers AI gpt-oss-20b
Open-weight, 128k context, reasoning and function calling.
Conversation stateDurable Object SQLite
One ordered, persistent database per DM or Space thread.
Shared metadataD1 + encrypted secrets
Installations, user links, workspace configuration and artifact index.
Background workQueues + Cloudflare Workflows
Fast Chat acknowledgment; durable reports and schedules.
PlaneShared Plane MCP v0.2.10 on AWS
One service per Plane instance; per-user token and fixed workspace slug.
Google dataCalendar + Drive REST APIs
Read-only domain-wide delegation as the verified Chat user.
KnowledgeAI Search + AI Gateway web search
Workspace-wide approved corpus; current external sources on demand.
ArtifactsPrivate R2 + authenticated viewer
HTML/JSON reports with access checks and source metadata.
End-to-end request
Every request follows the same traceable path.
- 01Invoke
A member DMs a workspace agent or @mentions it in a Space.
- 02Authenticate the event
The Worker verifies Google’s signed token, exact endpoint audience, issuer, expiry and Workspace domain.
- 03Fix the workspace
The verified Chat app identity resolves one installation and an immutable Plane workspace slug.
- 04Identify the person
The stable Google user ID maps to the person’s Plane token and Plane member. The model never sees credentials.
- 05Persist and acknowledge
The event is deduplicated, stored and queued before Google’s 30-second deadline.
- 06Resume memory
The conversation agent loads recent turns, a structured summary, open work, decisions and artifact references.
- 07Use live tools
The tool loop creates a short-lived MCP client with that person’s token and the installation’s slug. Calendar and Drive impersonate only the verified sender.
- 08Save the outcome
Tool calls, before/after facts, updated summary and job results are written to durable state.
- 09Reply as the agent
The workspace app’s own service account posts to the original DM or thread with an idempotent request ID.
- 10Publish heavy output
Standups, audits and dashboards run as Workflows, write private R2 artifacts, then post an authenticated link.
Authentication — four identities, never one
This separation is what makes the system safe and explainable.
Chat app identity
One Google Cloud project and service account per workspace agent. Receives verified events and posts as “Z360 Agent,” “Zikra Agent,” and so on.
Google human identity
Stable users/{id} and organization email from the verified event. This determines who asked; prompt text cannot change it.
Google data identity
A central service account has read-only domain-wide delegation. It impersonates the verified human, so Calendar and Drive enforce that person’s access.
Plane human identity
Each person connects a personal token once. Plane remains the final authority for workspace/project role and write permission.
Why the one-time Plane connection stays
Google authentication proves who sent the Chat message; it does not give Plane authority. A personal Plane token is the only verified Community Edition path that preserves native roles and human attribution today. After the one-time connection, the person can manage projects from Chat without returning to Plane. If “never visit Plane even once” becomes absolute, the alternative is a shared integration identity plus a separate authorization engine—simpler onboarding, materially worse security and auditability.
Plane MCP — enabled once, consumed at workspace level
The MCP service is shared; the authorization context is rebuilt for every human turn.
Service configurationOne pinned v0.2.10 process
The process points to the single self-hosted Plane base URL. If a second Plane instance is added later, it gets a second MCP process because the base URL is process-level.
Workspace configurationImmutable installation slug
Each Chat agent installation stores exactly one x-workspace-slug. Neither the user nor the model can replace it.
User configurationPersonal Plane token
A signed, single-use Chat configuration link binds agent + Google user. The backend validates the submitted token against Plane, maps the returned Plane user, encrypts the token, and never places it in conversation memory.
Per-turn clientShort-lived Streamable HTTP MCP
The AI SDK client opens the personal-token endpoint with that user’s Bearer token and the installation’s slug, exposes only the tested tool subset, then closes. This is required because several people can share one Space thread.
Network boundaryPublic HTTPS, private trust
The AWS-hosted MCP endpoint is reachable through TLS but protected for the agent gateway; Plane tokens and an additional service credential stay server-side.
Credential storage
D1 stores ciphertext and identity references, never plaintext credentials. Plane tokens and per-agent Google keys are encrypted with a per-record nonce; the encryption key lives only in a Cloudflare Worker secret. Conversation SQL stores token reference IDs, not secrets. The central Google delegation credential is also a Worker secret.
Multiple agents and memory isolation
Agent identity, conversation memory and tool authority are separate keys.
DM
agent_id + space_id + user_idPrivate memory for one person and one workspace agent.
Space thread
agent_id + space_id + thread_idShared memory only for that thread’s participants.
Unthreaded Space
agent_id + space_idShared Space context; use only where Chat threading is disabled.
Workspace catalog
agent_idProjects, members, states and approved knowledge shared inside one Plane workspace.
Conversation SQL
- Immutable turns
- Structured summary: goal, constraints, decisions, open items
- Tool calls and receipts
- Jobs and artifact references
- Idempotency records
D1 registry
- Agent installations and Google audiences
- Plane workspace slug and base URL
- User identity links and encrypted secret references
- Allowed Spaces, tools and schedules
- Workspace project/member cache
Private R2
- Standup HTML + source JSON
- Performance audit reports
- Dashboard snapshots
- Large tool results and exports
- Approved knowledge source snapshots
Memory rule
Memory supplies continuity, not current status. Ticket state, assignee, dates and project membership are refreshed from Plane before the agent answers or writes. Old transcript text is never treated as authoritative project data.
Tool design by required capability
The model receives a small task-specific surface, not Plane’s entire catalog.
| Capability | Live sources | Execution | Output |
|---|---|---|---|
| Prepare ticket | Projects, members, states, labels | Draft in memory; create via MCP when instructed | Ticket ID, link and receipt |
| Update ticket | Current item + activities | Read → update via personal token → read back | Before/after receipt |
| Standup | Cycle work, comments, activities, Calendar | Workflow aggregates by member and blocker | Chat summary + R2 report |
| Performance audit | Assignments, activity, dates, completion | Manager-scoped Workflow; evidence-first analysis | Private R2 artifact |
| Dashboard | Filtered item counts/lists and project catalog | Compute outside Plane; render HTML + source JSON | Authenticated R2 viewer |
| Answer question | Plane, Calendar, Drive, web, internal corpus | Short tool loop; source URLs/resource IDs preserved | Answer in originating DM/thread |
Community tool boundary
The current MCP catalog advertises tools whose backing routes are not present in inspected Community 1.3.1 source, including worklogs, milestones, initiatives, work-item types, custom properties and developer Pages. “Visible in tools/list” is not acceptance. The pilot exposes only tools that pass read/write/read-back against the installed Plane instance.
Visual explanation artifact
This responsive, single-page architecture site is the canonical visual artifact and is published as a Cloudflare R2-backed site. Its structure is: conclusion → visual system diagram → complete requirements ledger → option evidence → final stack and authentication sequence → admin setup → cost → tests and sources. “Copy for AI” exports the full text and source URLs for implementation handoff.
Workspace setup
How an administrator adds an agent
One platform setup, then a repeatable checklist per Plane workspace.
Platform operator · once
- 1
Deploy the shared Worker, Agent class, D1, Queue, Workflow and private R2 bucket.
- 2
Deploy the pinned Plane MCP compatibility service beside Plane on AWS and publish it through TLS.
- 3
Create the central Google data service account; a Workspace super administrator grants only Calendar and Drive read scopes.
- 4
Configure secret encryption, authenticated artifact viewer and the organization domain allowlist.
Plane workspace · repeat 5–10 times
- 1
Plane admin chooses the agent name/icon, immutable workspace slug, enabled capabilities, approved Drive corpus and schedule.
- 2
Google platform operator creates one Cloud project and configures the Chat app endpoint generated by the setup page.
- 3
Create that app’s service account, enable DM + Space interactions, and add its credential to the installation.
- 4
Workspace admin publishes the app as a private Marketplace app; install for a pilot Google Group or let users install it.
- 5
Each pilot member follows one private Chat configuration link and stores a Plane personal token. Daily work then stays in Chat.
- 6
Run the workspace test pack, add the app to relevant Spaces, then expand availability across the organization.
9:00
“Prepare today’s standup for the Z360 cycle.”
The agent reads current cycle work, recent activities and today’s relevant meetings, then returns a short summary and a private report link.
11:20
“Create a high-priority ticket from this thread and assign it to Maya.”
The Z360 identity fixes the workspace; Maya and the project are resolved live; Plane records the requesting person’s write.
16:30
“Show what changed since Sunday.”
The agent resumes the thread’s sprint context but rereads Plane before answering. Nothing depends on stale memory.
Credit strategy
Spend the credits where they remove complexity
Cloudflare runs the agent. AWS keeps Plane and its MCP close together. Fireworks remains a tested escape hatch.
Cloudflare
Use for Workers, Agents, Durable Objects, D1, Queues, Workflows, Workers AI, AI Search and R2. This single bill replaces a separate agent server, database, queue and artifact host.
AWS
Keep existing self-hosted Plane and one lightweight MCP service per Plane instance here. Do not move the agent runtime to AWS merely to consume a larger credit.
Fireworks
Reserve for an evaluation and provider-failure fallback. Do not make it a day-one dependency while Workers AI is already inside the selected runtime.
Illustrative active-month model
Assumption: 10,000 user requests across all workspaces; three model steps per request; 6,000 input and 800 output tokens per step.
Inference uses Cloudflare’s published $0.20/M input and $0.30/M output rates. Runtime/storage is an architectural estimate, not a vendor quote. Web-search upstream usage is excluded because credit coverage is contract-specific.Primary
gpt-oss-20bOpen-weight, 128k context, tool calling and reasoning at the lowest integrated complexity.
Model documentation ↗If evaluation fails
gpt-oss-120bOne configuration change inside Workers AI; use only if real Plane tests prove the 20B model is not reliable enough.
Model documentation ↗Not chosen
Dynamic multi-provider routingIt adds evaluation, billing and failure modes before a real need exists. Keep Fireworks configured and tested, but inactive.
Before production
Compatibility tests and honest open items
The architecture is decided. These checks resolve documentation gaps in the installed products.
Plane MCP headers
Prove v0.2.10 initialization and read/write/read-back with Bearer token + workspace slug; record whether the setup page’s alternate header works.
Community edition surface
Check live “Build your own” OAuth UI/routes. If absent, run the personal-token-only MCP entry point. Probe every proposed tool against the live instance.
Role fidelity
Run the same MCP actions as an Admin, Member and Guest; test wrong workspace, removed member, revoked token and 60-request limit.
Google Chat delivery
Verify OIDC, duplicate retries, 30-second acknowledgment, DM reply, threaded Space reply, private Space reply and async app posting.
Google data boundary
Prove domain-wide delegation impersonates only the verified sender; test permitted and forbidden Calendar/Drive resources; inventory scopes and confirm no mail scope.
Memory isolation
Restart the runtime, resume a DM and a Space thread, then attempt cross-agent, cross-space and cross-user retrieval. All must stay isolated.
Model evaluation
Run 50–100 real ticket, standup, audit and dashboard cases. Measure tool choice, argument accuracy, factual grounding and write receipt correctness before choosing 20B or 120B.
Artifacts and cost
Open private R2 links as authorized and unauthorized users; reconcile one dashboard to Plane; verify which Cloudflare products and unified-billing search calls the credit covers.
Unresolved evidence — do not guess
Plane OAuth on Community
Current docs describe it; inspected Community 1.3.1 source does not prove it. Live-instance test decides.
Plane MCP incoming PAT header
Setup page and v0.2.10 executable test conflict. The compatibility spike records the working contract.
Retention period
No company policy was supplied for Chat transcripts, performance audits or artifacts. Storage supports deletion and configurable retention; the business policy must be set before broad rollout.
Internal company data definition
The source systems beyond Drive were not named. V1 indexes only an approved Drive/R2 corpus; additional systems require an explicit source and permission model.
Web-search credit coverage
Cloudflare documents unified billing and web-search providers, but promotional credit applicability is contract-specific. Confirm it in the account.
Assumptions used
- All 5–10 workspaces are on one self-hosted Plane instance and one Google Workspace tenant.
- Normal use means no daily Plane login; a one-time personal-token connection is acceptable to preserve native permissions.
- Calendar and Drive are read-only. Gmail remains out of scope.
- Artifacts are internal by default and must not be public R2 objects.
- The agent responds to DMs, mentions and explicit schedules; it does not watch every Space message.
- A Google Workspace super administrator and Google Cloud operator are available for initial registration.
Primary evidence
Sources
Official documentation and project repositories checked on 15 July 2026. Claims marked “Decision” are our architectural inference.
Google Chat & Workspace 14 sources
Configure Google Chat APICloud project, visible identity, endpoint
Verify Chat requestsOIDC signature, sender and audience
Receive and respond30-second deadline and async path
Authenticate and authorizeApp vs user authentication
Create messagesApp posts, private replies, request IDs
Identify usersStable Chat user resources
Connect external servicesREQUEST_CONFIG flow
Publish Marketplace appsPrivate organization listing
Marketplace SDKVisibility and install options
Service account OAuthDelegated authorization
Workspace credentialsCredential types and delegation
Calendar scopesRead-only event access
Drive scopesdrive.file vs drive.readonly
Shared drivesService-account storage boundaries
Plane & MCP 10 sources
Self-host Plane MCPDeployment, URLs and OAuth setup
Plane MCP setupTransports and personal-token headers
Plane MCP toolsCurrent tool catalog
Plane API introductionAuthentication, errors and limits
MCP v0.2.10Pinned release
v0.2.10 integration testExecutable header behavior
Header authenticatorToken validation path
Community route registryVerified API surface
Community API authenticationPersonal token identity
Plane webhooksEvent-triggered refresh option
Cloudflare 13 sources
Cloudflare Agents SDKRuntime capabilities
Agent stateDurable SQLite
Durable ObjectsOne object per logical unit
SQLite storage APIPersistent local SQL
Agent queuesAsynchronous work
Agent WorkflowsDurable long tasks
MCP clientStreamable HTTP and custom headers
AI SearchManaged workspace retrieval
AI Gateway web searchCurrent external information
R2 from WorkersArtifact storage
R2 public accessWhy reports remain private
gpt-oss-20bContext, tools and price
Workers AI pricingPublished token rates
Framework alternatives & patterns 12 sources
Bedrock Agents ClassicCapabilities and new-customer cutoff
Bedrock agent memorySessions and retention
Amazon Bedrock AgentCoreRuntime, memory, identity and MCP
Deep AgentsHarness, memory, subagents and MCP
AI SDK agentsToolLoopAgent
Chat SDKCross-platform abstraction
Chat SDK adaptersGoogle Chat Beta status
Workflow SDKPortable durable execution
Introducing EvePublic-preview status and scope
AegraLangGraph runtime stack
Claude TagShared agent identity pattern
Slack agent contextThread memory and summarization
Final answer
Build one gateway, not ten agent platforms.
Each workspace gets its own trusted face in Google Chat. Behind that face, one Cloudflare system verifies identity, remembers the right conversation, calls Plane with the right person’s permission, reads only their Google data, and publishes private reports. It is cheaper, simpler and more auditable than the AWS, deep-agent or Vercel-hosted alternatives.