A lot of the recent Pea R&D work has been about APIs. That sounds ordinary at first. Most software eventually connects to mail, calendars, files, cloud services, chat systems, and internal tooling.
For Pea, the harder question is not simply whether an external service can be reached. The harder question is whether it can be reached without becoming an authority surface.
That is the shape of the new API plane: Google services, Microsoft Graph, Zoho Mail, messaging surfaces, and source-development tools are being treated as governed capability substrates. They can provide evidence. They can expose bounded actions. They can return typed results. But they do not get to become Pea's planning system, decision system, memory system, or instruction source.
An external API should be useful without becoming sovereign.
Google Surfaces
Google has been a major focus. The work now covers Google Cloud, Google Workspace, Gmail, Calendar, Drive, Docs, Sheets, and Vertex-style model surfaces.
The important part is the contract shape. A Drive file listing becomes bounded file evidence. A Drive change sync uses provider-neutral cursor discipline rather than leaking raw provider tokens upward. Gmail and Calendar reads become canonical message or event records. Docs and Sheets are handled through artifact contracts and update gates rather than open-ended document mutation.
Vertex work follows the same posture. Generation, embedding, and vector-search operations are represented as external evidence paths, not as Pea Planning, Decision, memory, or vector-store authority. That distinction matters. A model output can be evidence in a governed runtime, but it should not silently promote itself into control.
Microsoft Graph
Microsoft Graph has grown into a broad test surface: Outlook mail, calendar, Teams messages, OneDrive and SharePoint files, Word documents, Excel workbooks, subscriptions, and delta cursors.
The same rules keep appearing. Read paths are bounded and canonicalized. Sync paths use cursor refs rather than raw provider cursors. Mail and calendar writes require explicit gates. Teams sends require a trusted approval path. File and Office mutations require bounded source references, not raw file bodies, spreadsheet cells, formulas, or provider-shaped payloads passed straight through the system.
That sounds fussy, but the fussiness is the point. Graph is powerful. A governed agent should be able to use that power only through visible, typed, auditable handoffs.
Zoho Mail And The Smaller Surfaces
Zoho Mail is now covered as a mail substrate too: account and folder reads, message listing, message retrieval, attachments, draft-first behavior, and send gates. The design is deliberately consistent with Gmail and Graph mail. Messages are evidence. Attachments become artifacts. Sending mail remains a governed action, not a casual side effect.
Alongside that, there is provider specification work for messaging surfaces and source-development access. These are not being treated as back doors into Pea. Incoming provider events are triggers or evidence, not instructions. That boundary keeps the runtime from confusing "something happened elsewhere" with "Pea has been authorized to act."
The Gate Is The Product
The pattern is becoming very clear now. A request travels through functional requirements, semantic task projection, capability lowering, engine execution, Decision authorization, capability dispatch, and then the API runtime. By the time an adapter sees a request, it should already carry the evidence that the action is allowed.
Read-only sync can be system-invoked when it has the right scheduler or lease authority. Mutations need stronger posture: explicit user intent, trusted approval references, decision authorization, capability invocation references, and provider-specific operation contracts. Approval-like data smuggled through provider payloads or metadata should not count.
That may be the most important design principle in the whole API plane. External services should be reachable, but not persuasive. They can return data, but they cannot grant themselves authority.
Where It Stands
This is still R&D. A lot of the recent work is contract-level and fake-client based rather than live provider transport. That is intentional. The current priority is to prove boundaries, typed evidence shapes, approval gates, cursor discipline, and raw-provider containment before live credentials and real network calls enter the picture.
The visible progress is not only "Pea can talk to more APIs." It is more specific than that: Pea is learning how to expose outside capabilities without dissolving the runtime boundary that makes it governable.
Status: this is a public-safe Pea R&D draft. It describes the architecture and direction of the API plane without exposing credentials, private provider configuration, live endpoints, or implementation-sensitive internals.