ASANMOD Chat Bridge – Google Workspace AI Operator

Native Cloud AI operator running on Google Cloud Run that seamlessly executes 11 Google Workspace services directly inside Google Chat using Antigravity Engine & Model Context Protocol (MCP).

Comment

## Inspiration

Most enterprise AI assistants stop at generating text. Real work still requires employees to open Gmail, Calendar, Drive, Docs, Sheets, and multiple administration screens, then manually verify whether each action succeeded.

We built GAIAI Agents, powered by ASANMOD Chat Bridge, to close that gap.

Our goal was not to place another chatbot beside Google Workspace. We wanted Google Chat itself to become a secure operating surface where an authorized employee can request, execute, verify, and audit real Workspace operations without leaving the conversation.

## What it does

ASANMOD Chat Bridge is a production-deployed AI operations layer for Google Workspace.

A user writes a request naturally in Turkish or English inside an authorized Google Chat Space. The system verifies the sender, organization, Space membership, permissions, OAuth scopes, and conversation context before selecting and executing the necessary tools.

Its complete-tier MCP catalog covers 11 Google Workspace services:

  • Google Docs
  • Google Sheets
  • Google Drive
  • Gmail
  • Google Calendar
  • Google Tasks
  • Google Slides
  • Google Chat
  • Google Contacts
  • Google Forms
  • Google Apps Script

The product supports multi-step operations rather than isolated prompts. For example, it can find information in Gmail, create a structured document, write business data into Sheets, schedule a Calendar event, create follow-up Tasks, and report the verified results back to the original Chat thread.

Every operation produces a lifecycle trail:

User request → verified identity and authorization → selected Workspace tools → live progress → provider execution → provider readback → independent final delivery → audit and usage record

A model saying “completed” is never accepted as proof. Success requires a terminal result and, where applicable, a readback from the real Google provider.

## How we built it

### Google Antigravity as the native execution engine

Each user turn runs through a real Antigravity CLI process with native tool binding and structured stream-json events.

We deliberately separated the process lifecycle from conversation memory:

  • Every user turn starts a fresh CLI process.
  • The durable conversation_id restores the existing conversation.
  • All tool operations belonging to that turn execute inside the same process.
  • A failed or stale process cannot contaminate the following turn.

This gives us clean-process reliability without losing multi-turn context.

### MCP-powered Google Workspace operations

We packaged workspace-mcp==1.21.2 as a portable complete-tier runtime bundle. The engine discovers Workspace tools dynamically and executes them using the verified sender’s own OAuth authority.

Effective tool access is calculated as:

User permissions ∩ organization entitlements ∩ granted OAuth scopes ∩ runtime tool allowlist

The model cannot expand its own authority through a prompt or tool description.

### Three separate identity roles

One of the most important architectural decisions was refusing to treat a single credential as an all-powerful agent identity.

ASANMOD uses three distinct roles:

  • Owner OAuth reads and claims inbound messages from an authorized Space.

  • Verified Sender OAuth executes Workspace operations with the real user’s permissions.

  • HumanBot Delivery OAuth sends progress and final responses back to Google Chat.

The delivery identity can never silently become the user’s Workspace data identity.

### Independent progress and final delivery

Long-running agent work must not lose its result because a progress update was delayed.

We separated progress and completion into independent channels:

  • Progress updates are best-effort visibility.
  • The final response is delivered through a separate provider POST.
  • The returned provider message name and text are read back.
  • A failed progress PATCH cannot suppress a successfully verified final response.

### Google Cloud production architecture

ASANMOD Chat Bridge runs as a dedicated standalone product on Google Cloud:

  • Cloud Run Gen2: Next.js product surface, Express API, poller, and agent runtime

  • Cloud SQL for PostgreSQL: organizations, users, Spaces, conversations, runs, and audit evidence

  • Secret Manager: runtime credential bindings without embedding secrets in the image

  • Artifact Registry: immutable container images

  • Google Chat and Workspace APIs: inbound messages, tool execution, delivery, and provider readbacks

  • Embedded Redis: standalone queue and runtime coordination

The deployed revision uses an immutable image digest, receives 100% of production traffic, and reports healthy database and Redis connections.

## Challenges we ran into

### Long-lived agents accumulated stale runtime state

Our first architecture kept CLI processes alive between turns. Although this reduced startup time, it introduced stale tool-discovery state, timeout risk, and difficult recovery behavior.

We replaced it with a fresh-process-per-turn architecture. Conversation continuity now belongs to the explicit conversation key—not to the lifetime of an operating-system process.

### Google Chat delivery could block behind progress updates

A delayed progress-message creation or PATCH could postpone the final answer even after the agent completed its work.

We redesigned final delivery as an independent, provider-verified operation. Progress can fail without losing the actual business result.

### Tool recovery could accidentally hide real failures

A broad recovery rule could treat an unrelated successful operation as proof that an earlier failure had been resolved.

We tightened recovery correlation. A failed tool step is cleared only by:

  • success from the same tool call,
  • a matching successful tool operation, or
  • a provider readback for the exact affected resource.

Unresolved tool errors keep the complete turn in a fail-close error state.

### Enterprise authorization required more than OAuth login

Authentication alone does not prove that a user may access a Space, organization, service, or resource.

We bound every conversation and execution to organization, user, Space, and thread identity. Cross-tenant access is rejected without leaking whether the target resource exists.

## Accomplishments that we're proud of

  • Deployed a dedicated production revision to Google Cloud Run using an immutable Artifact Registry digest.

  • Turned Google Chat into an operational interface for 11 Workspace services.

  • Completed an 11-service Workspace Hero acceptance run with 70 tool-evidence events, 13 provider readbacks, zero unresolved tool errors, and verified cleanup.

  • Validated a governed multi-model inventory and conversation-preserving model hot- swap flow.

  • Proved live Google Chat message ingestion, native Antigravity execution, MCP tool use, provider readback, and independently verified final delivery.

  • Preserved conversation context across disposable CLI processes.

  • Enforced fail-close behavior for malformed streams, missing results, tool failures, identity mismatches, and cross-tenant access.

  • Kept runtime artifacts and credentials outside the source repository and container image.

  • Built a dedicated Chat Bridge product surface without exposing the surrounding IKAI HR application or its APIs.

  • Recorded run, tool, provider, delivery, and audit evidence instead of relying on model-generated success messages.

## What we learned

  • The lifetime of an AI process should not define the lifetime of a conversation.
  • Reliable enterprise agents need disposable execution and durable context.
  • Provider readback is more valuable than confident model narration.
  • Progress UX and final business delivery must be independent.

  • OAuth identity, message-delivery identity, and cloud-runtime identity are different security roles.

  • MCP becomes significantly more powerful when tool discovery, authorization, execution, and evidence share one contract.

  • A production agent should fail visibly when evidence is incomplete rather than manufacture a successful-looking answer.

## What’s next for ASANMOD Chat Bridge

  • Complete Google OAuth verification and Workspace Marketplace distribution.
  • Add scheduled and event-driven Workspace operations.

  • Expand multimodal handling for Google Chat documents, images, and business attachments.

  • Introduce organization-specific agent skills and reusable operational policies.

  • Extend provider-backed recovery for more complex multi-tool workflows.

  • Scale beyond the current single-owner polling topology using distributed claims and ownership leases.

  • Add an optional supervised warm-session mode for workloads where performance gains can be proven without weakening isolation or recovery.

Built With

Share this project:

Updates

Submission history