Project Think is Cloudflare’s next-generation Agents SDK for building persistent, scalable AI agents. It combines durable execution, sub-agents, persistent sessions, sandboxed code execution, and runtime-created extensions, while allowing developers to use individual primitives or an integrated Think base class. Its central argument is that agents should run as durable, one-to-one infrastructure rather than ephemeral processes on laptops or permanently running servers.
## Why Agents Need a New Foundation
- Coding agents increasingly act as general-purpose assistants by reading context, writing and executing code, observing results, and iterating.
- Existing agents are limited by:
- Dependence on a laptop or costly VPS
- Fixed costs while idle
- Manual installation, updates, identity, and secret management
- Unlike traditional applications, agents are typically one-to-one: each user, task, or conversation may require a distinct agent.
- Supporting millions of concurrent agents with always-on containers would be economically impractical.
## Project Think’s Core Primitives
Project Think introduces:
- Durable execution through fibers, including checkpointing, crash recovery, and automatic keepalive
- Isolated sub-agents with independent SQLite databases and typed RPC
- Persistent, searchable sessions with message trees, branching, and compaction
- Sandboxed code execution using Dynamic Workers, codemode, and runtime npm resolution
- An execution ladder spanning workspaces, isolates, npm packages, browsers, and sandboxes
- Self-authored extensions that let agents create tools dynamically
## Long-Running Agents with Durable Objects
- Each agent is implemented as a Durable Object with:
- A stable identity
- Persistent SQLite-backed state
- Message-based wake-up
- Automatic hibernation when idle
- Agents can resume after HTTP requests, WebSocket messages, alarms, or inbound email.
- Hibernated agents consume no compute, allowing many more agents than an always-on VM or container model.
- Durable Objects provide automatic routing, recovery, and per-agent state without separately managed load balancers, databases, or process supervisors.
- For example, 10,000 agents active only 1% of the time require capacity for roughly 100 active agents rather than 10,000 continuously running instances.
## Durable Execution with Fibers
- Long LLM calls and multi-step workflows can be interrupted by deployments, restarts, or resource limits.
- `runFiber()` makes a function invocation durable by:
- Registering it in SQLite before execution
- Allowing progress to be checkpointed with `stash()`
- Recovering interrupted work through `onFiberRecovered`
- Agents can save intermediate findings, resume from the latest checkpoint, and broadcast progress to clients.
- The SDK automatically keeps the agent alive while a fiber runs.
- `keepAlive()` and `keepAliveWhile()` support active work lasting minutes or longer, such as CI pipelines, design reviews, and video generation.
Project Think’s recommendation is to treat agents as persistent, addressable infrastructure: use the low-level primitives for customization, or adopt the Think base class for a faster, integrated starting point.
Cloudflare’s experimental `@cloudflare/voice` package adds real-time voice to existing Agents SDK applications without requiring a separate voice framework. Voice interactions use the same Durable Object, WebSocket connection, tools, and SQLite-backed history as text interactions. The package provides ready-made STT and TTS integrations while keeping provider interfaces open for alternative speech, telephony, and transport systems.
## Voice Support for Existing Agents
- `withVoice(Agent)` enables full conversational voice agents.
- `withVoiceInput(Agent)` supports speech-to-text-only features such as dictation and voice search.
- React applications can use `useVoiceAgent` and `useVoiceInput`.
- Framework-independent clients can use `VoiceClient`.
- Built-in Workers AI providers include:
- Deepgram Flux for continuous speech-to-text
- Deepgram Nova 3 for speech-to-text
- Deepgram Aura for text-to-speech
- Developers can get started without external API keys.
## Minimal Server and Client Setup
- A voice agent extends a class created with `withVoice(Agent)`.
- The server configures a transcriber and TTS provider, then implements `onTurn()`.
- `onTurn()` receives the user’s transcript and returns the agent’s response.
- React clients can display:
- Connection status
- Interim and finalized transcripts
- Conversation messages
- Start, end, and mute controls
- Non-React applications can connect through `@cloudflare/voice/client`.
## How the Voice Pipeline Works
- The browser captures 16 kHz mono PCM microphone audio.
- Audio streams over the agent’s existing WebSocket connection.
- A continuous STT session remains active for the duration of the call.
- The speech-to-text model detects completed utterances and produces stable transcripts.
- Each transcript is passed to `onTurn()` for application or LLM logic.
- The response is synthesized into audio and streamed back to the client.
- Streamed responses can be sentence-chunked so audio begins playing before the full response is complete.
- User and agent messages are persisted in the Durable Object’s SQLite database, surviving reconnections and deployments.
## Extensible Provider Architecture
- The package is designed not to lock developers into one fixed voice stack.
- Small provider interfaces allow speech, telephony, and transport providers to build integrations.
- Developers can mix and match components based on their application’s requirements.
- Voice therefore becomes another interaction mode for the same stateful agent rather than a separate application architecture.
Cloudflare’s approach is best suited to developers who already use the Agents SDK and want to add conversational voice while preserving existing state, tools, persistence, and connection patterns. Since the package is experimental, teams should evaluate provider support and API stability before relying on it in production.
GitLab released patch versions 18.10.3, 18.9.5, and 18.8.9 on April 8, 2026, addressing important security and bug fixes. Self-managed CE and EE installations should upgrade immediately, while GitLab.com is already patched and GitLab Dedicated customers need no action. The fixes cover unauthorized access, denial-of-service vulnerabilities, code injection, XSS, and information disclosure.
## Release Scope and Upgrade Guidance
- The patches apply to GitLab Community Edition and Enterprise Edition.
- Administrators should upgrade installations affected by the listed vulnerabilities to the latest supported patch release.
- GitLab issues describing security vulnerabilities will become public 30 days after the release in which they were fixed.
- Patch releases are generally issued on the second and fourth Wednesdays, with urgent ad-hoc releases for critical vulnerabilities.
## Authentication and Authorization Fixes
- **CVE-2026-5173 (CVSS 8.5):** Authenticated users could invoke unintended server-side methods through WebSocket connections.
- **CVE-2026-2619 (CVSS 4.3):** Auditor users could modify vulnerability flag data in private projects through the AI detection API.
- **CVE-2026-1752 (CVSS 4.3):** Developers could modify protected environment settings through authorization flaws in the Environments API.
- **CVE-2026-2104:** CSV exports could expose confidential issues assigned to other users because of insufficient authorization checks.
## Denial-of-Service Vulnerabilities
- **CVE-2026-1092 (CVSS 7.5):** Unauthenticated attackers could crash or disrupt services through malformed JSON sent to the Terraform state lock API.
- **CVE-2025-12664 (CVSS 7.5):** Repeated unauthenticated GraphQL queries could cause denial of service.
- **CVE-2026-1403 (CVSS 6.5):** Authenticated users could disrupt Sidekiq workers by importing malformed CSV files.
- **CVE-2026-1101 (CVSS 6.5):** Authenticated users could overload GitLab through improperly validated GraphQL SBOM queries.
## Code Execution and Cross-Site Scripting
- **CVE-2026-1516 (CVSS 5.7):** Crafted Code Quality report content could leak the IP addresses of users viewing the report.
- **CVE-2026-4332 (CVSS 5.4):** Authenticated users could execute arbitrary JavaScript in other users’ browsers through customizable analytics dashboards.
## Information Disclosure
- **CVE-2025-9484 (CVSS 4.3):** Certain GraphQL queries could reveal other users’ email addresses to authenticated users.
- The release also fixes CSV export authorization issues that could expose confidential issue data.
Administrators of self-managed GitLab CE or EE instances should apply 18.10.3, 18.9.5, or 18.8.9 as soon as possible, depending on their supported release branch.
MessagingHub turns chat into a reusable platform rather than rebuilding it for each product domain. It separates domain-specific authentication and business context from common chat capabilities, allowing chatbot, customer-support, direct, and group conversations to share the same infrastructure. Its policy-driven design, modular architecture, and configurable metadata aim to reduce integration complexity while preserving flexibility.
## Why MessagingHub Was Introduced
- Chat requirements vary across chatbots, customer support, one-to-one conversations, and group chats.
- Building each implementation independently increases integration points, system complexity, development cost, and the impact of small changes.
- MessagingHub is designed as a domain-independent platform that can be adopted by multiple services.
- The platform focuses on chat itself while absorbing external requirements through generalized, reusable structures.
- It is currently used by a Japanese food-delivery service for users, drivers, customer-service agents, and restaurants.
## Supported Chat Types
- **Chatbots:** Delivered through a public web URL embedded in a partner service’s webview. Scenarios are created and deployed through an administrative console.
- **Inquiry chat:** A user is matched with a customer-service agent. The partner domain supplies contextual information such as user details and previous consultation history.
- The platform is also structured to support direct one-to-one and group conversations.
## Core Platform Policies
### Authentication and User Identification
- MessagingHub does not manage user accounts or domain authentication.
- Partner systems handle login, registration, permissions, and the decision of whether a user may access chat.
- After authenticating a user, the partner requests a connection token and passes it to the client.
- The client uses the token to establish a WebSocket connection; unauthenticated direct access is not allowed.
- A user is identified by a `client_id`, combining the partner domain identifier with the partner’s user identifier.
- Display names, profile images, and `pushToken` values are supplied and updated by the partner system.
### Service Contexts and Room Types
- A **service context** defines which roles may communicate, such as:
- `Driver2CS`
- `Consumer2CS`
- A **chat room type** defines the conversation structure, such as:
- `USER_DIRECT`
- `USER_GROUP`
- `INQUIRY_CHATBOT`
- `INQUIRY_CHAT`
- The combination of service context and room type controls room creation, participation, and message permissions.
### Room Lifecycle and Data Retention
- General room states progress from `WAIT` or `PENDING`, to `SERVICE`, and eventually to `DISABLE` or `BLOCK`, where sending messages is prohibited.
- Messages and potentially identifying data are encrypted at rest.
- Data can be deleted immediately when all participants leave a room.
- Partners can also configure retention periods for automatic deletion of older data.
## Modular Architecture
MessagingHub is not a monolithic chat server. Its components have clearly separated responsibilities and communicate through loosely coupled events.
- **`connection-manager`**
- Manages WebSocket connections and validates connection tokens.
- Tracks user connection status.
- Helps identify active chatbot scenario connections during `SOFT STOP` processing.
- **`chat-app`**
- Implements core chat logic, including message delivery, room creation, state transitions, and read status.
- Exposes functionality as commands that can be combined for different chat types.
- **`message-router`**
- Determines where recipients are connected.
- Routes messages from the chat server to the appropriate connection-management component.
- **`notification-app`**
- Sends push notifications when recipients are offline or the application is in the background.
- Uses partner-provided `pushToken` values and room-level notification settings.
- **`admin-hub`**
- Manages chatbot scenario editing and deployment.
- Handles agent accounts, roles, service contexts, events, webhooks, monitoring, and statistics.
## Command-Based Chat Flows
- Chat behavior is modeled as composable commands.
- Common commands provide functionality shared across chat types.
- Chatbot and inquiry-chat features add more specialized commands.
- This “building block” approach allows business requirements to be assembled without creating a separate chat implementation for every domain.
## Data Model
MessagingHub separates operational data from core chat data:
- **`chat` database:** Stores users, rooms, participants, metadata, and messages.
- **`chat_operation` database:** Stores operational and administrative information.
Important entities include:
- `chat_user`: Uniquely identifies users by `client_id`.
- `chat_room`: Represents rooms and enforces room uniqueness at the schema level.
- `chat_member`: Connects users to rooms.
- `chat_room_meta`: Stores participant-specific state, including read position, push settings, input restrictions, and room status.
- `chat_log`: Stores encrypted messages in a one-to-many relationship with rooms.
- `prev_chat_log_id` preserves message ordering.
- Room-level first and last message IDs, together with participant read positions, support unread-count calculation.
- Partner metadata such as `system_data`, `search_data`, `user_details`, and `descriptions` is stored as JSON. MessagingHub preserves and forwards it without interpreting its domain meaning.
- Scheduling, event, and webhook history are tracked through tables such as `chat_schedule`, `chat_event_record`, and `webhook_event_record`.
- `service_context`, `chat_event`, and `webhook` configure allowed role relationships, event-message policies, and webhook behavior.
## Chatbot Scenario Management
### Flexible Scenario Structure
- Administrators manage multiple chatbot scenarios through an editing tool.
- Scenarios define messages, selectable options, and answers.
- Webhooks can dynamically generate response content.
- The hierarchical data model supports a broad range of chatbot flows.
### Version Deployment and `SOFT STOP`
Chatbot scenarios transition through:
`WAIT → SERVICE → SOFT STOP → DISABLE`
- A newly deployed scenario becomes `SERVICE`.
- The previous scenario moves to `SOFT STOP`.
- Existing users can finish conversations using the previous version.
- New users are directed to the latest scenario.
- A scheduler periodically checks whether any users still have active connections to the old scenario.
- Connection information is collected from connection-management servers and stored in a shared resource.
- Once no active users remain, the old scenario is disabled and the scheduler stops.
- This provides backward compatibility without disrupting users during deployment.
## Inquiry Chat Metadata and Lifecycle
### Partner-Defined Metadata
Inquiry chat allows partner domains to provide information that helps agents handle cases effectively:
- Search data for finding conversations
- User details shown to agents
- Custom display data
- Event data for surveys or webhooks
- Basic consultation descriptions
- Room settings such as room names and push-notification titles
- Tracking data for identifying and mapping rooms in partner systems
### Room Lifecycle
Inquiry rooms generally move through:
`PENDING → SERVICE → DISABLE → BLOCK`
- `PENDING` represents the period while the user waits for an agent match.
- `SERVICE` is the active consultation period.
- `DISABLE` indicates that the consultation has ended.
- `BLOCK` prevents further messaging after closure.
MessagingHub’s overall approach is to keep the platform’s responsibilities narrow and reusable while allowing partner domains to own authentication, user meaning, and business-specific metadata. For organizations supporting multiple chat scenarios, a policy-driven, command-based platform with separated components and explicit data ownership can significantly reduce duplication and integration risk.
The 7th Woowacourse crew has successfully launched three distinct services, demonstrating that modern software engineering requires a synergy of technical mastery and "soft skills" like product planning and team communication. By owning the entire lifecycle from ideation to deployment, these developers moved beyond mere coding to solve real-world problems through agile iterations, user feedback, and robust infrastructure management. The program’s focus on the full stack of development—including monitoring, 2-week sprints, and collaborative design—highlights a shift toward producing well-rounded engineers capable of navigating professional environments.
### The Woowacourse Full-Cycle Philosophy
* The 10-month curriculum emphasizes soft skills, including speaking and writing, alongside traditional technical tracks like Web Backend, Frontend, and Mobile Android.
* During Level 3 and 4, crews transition from fundamental programming to managing team projects where they must handle everything from initial architecture to UI/UX design.
* The process mimics real-world industry standards by implementing 2-week development sprints, establishing monitoring environments, and managing automated deployment pipelines.
* The core goal is to shift the developer's mindset from simply writing code to understanding why certain features are planned and how architecture choices impact the final user value.
### Pickeat: Collaborative Dining Decisions
* This service addresses "decision fatigue" during group meals by providing a collaborative platform to filter restaurants based on dietary constraints and preferences.
* Technical challenges included frequent domain restructuring and UI overhauls as the team pivoted based on real-world user feedback during demo days.
* The platform utilizes location data for automatic restaurant lookups and supports real-time voting mechanisms to ensure democratic and efficient group decisions.
* Development focused on aligning team judgment standards and iterating quickly to validate product-market fit rather than adhering strictly to initial specifications.
### Bottari: Real-Time Synchronized Checklists
* Bottari is a checklist service designed for situations like traveling or moving, focusing on "becoming a companion for the user’s memory."
* The service features template-based list generation and a "Team Bottari" function that allows multiple users to collaborate on a single list with real-time synchronization.
* A major technical focus was placed on the user experience flow, specifically optimizing notification timing and sync states to provide "peace of mind" for users.
* The project demonstrates the principle that technology serves as a tool for solving psychological pain points, such as the anxiety of forgetting essential items.
### Coffee Shout: Real-Time Betting and Mini-Games
* Designed to gamify office culture, this service replaces simple "rock-paper-scissors" with interactive mini-games and weighted roulette for coffee bets.
* The technical stack involved challenging implementations of WebSockets and distributed environments to handle the concurrency required for real-time gaming.
* The team focused on algorithm balancing for the weighted roulette system to ensure fairness and excitement during the betting process.
* Refinement of the service was driven by direct feedback from other Woowacourse crews, emphasizing the importance of community testing in the development lifecycle.
These projects underscore that the transition from a student to a professional developer is defined by the ability to manage shifting requirements and technical complexity while maintaining a focus on the end-user's experience.
