Planned capability

Agent product builders

Give agents narrow tools with human-owned authority

Plan communication tools for agents as typed, tenant-scoped operations over accounts a user explicitly connected. DewEngine should expose capability and evidence while the agent product owns model behavior, memory, approval, purpose, recipient selection, and the decision to invoke any write.

Illustrative product surface. The workflows below are planned, not a live connector.

Talk to us ↗Read technical guides →

Planned boundary

No customer agent tool surface is implemented

This AI agent use case is planned and not callable. DewEngine has no released MCP server, agent SDK, delegated agent identity, policy engine, approval queue, prompt-injection defense, or communication tool catalog.

Current evidence: The architecture proposes a small MCP mapping onto the same REST command and query services, but repository evidence is limited to a partial TypeScript SDK and development control plane. No agent invocation reaches a provider through a released contract.
Target contract: Issue a delegated principal with explicit workspace, account, resource, operation, purpose, and expiry constraints rather than sharing a broad server key; Describe each tool with current account capability and structured side effects, then represent provider-visible writes as idempotent reviewable commands; Return source identifiers, timestamps, confidence, and outcome state so an agent cannot treat generated prose or queued work as provider fact
Known limits: DewEngine will not host the model, secure the agent's memory, verify its reasoning, prevent every prompt injection, choose recipients, or establish consent; Tool schemas cannot eliminate hallucination, confused-deputy risk, stale context, provider ambiguity, policy changes, or damage from an overbroad application permission
Release gates: Release stable underlying resources and build a deliberately small MCP catalog generated from capability evidence; Implement delegated identity, read/write separation, approval receipts, budget and rate policy, revocation, audit, and stale-context checks; Run adversarial evaluations for prompt injection, tenant crossover, tool confusion, duplicate writes, hidden side effects, and uncertain outcomes

Tool design

Prefer explicit verbs over a universal communication tool

An agent should select from narrow operations whose required account, target, content, and side effect are visible in the schema. A read tool cannot mutate provider state; a draft tool cannot send; a scheduling proposal is distinct from creating an attendee-notifying event. Small verbs make approval, simulation, and evaluation materially easier.

Exclude unreleased provider methods from tool discovery
Return a capability reason when an operation is unavailable

Implementation authority

Bind every invocation to a delegated principal

The agent runtime presents a short-lived grant tied to the customer workspace, acting user or automation, allowed accounts, operations, and policy version. DewEngine authorizes that principal again when a command reaches dispatch. This limits the damage from copied tool output, delayed execution, compromised memory, or a workflow whose owner later revoked access.

Never place reusable provider authorization inside model context
Record agent, user, policy, and approval identity separately

Human review

Approve the exact side effect, not a vague plan

A review surface should show acting account, recipients, native conversation, final content, attachments, notification behavior, purpose, and expiry. The receipt binds those values cryptographically or by immutable version. If the agent changes content, target, timing, or provider after approval, the prior receipt no longer authorizes the command.

Let low-risk reads and high-risk writes use different policies
Expire approval when relevant account or conversation state changes

Evidence discipline

Keep model statements separate from source observations

Tool results should label application input, provider observation, DewEngine normalized state, and derived match suggestions. The agent can summarize those facts, but its summary is not written back as source truth. Before acting on old context, the runtime checks resource version and account health so a polished plan cannot override a newer reply or disconnect.

Include stable citations to resource and event identifiers
Require a fresh read for consequential stale-state writes

Evaluation gate

Test refusal and recovery, not only task completion

Agent conformance should include malicious message content, forged tool instructions, swapped tenant IDs, hidden recipients, duplicate model calls, expired approvals, ambiguous provider timeouts, and an inbound reply during planning. A passing system refuses or pauses safely, explains the boundary, and preserves enough evidence for an operator to resume without repeating work.

Measure unauthorized-action prevention and duplicate-write rate
Run evaluations against fake providers before any consented live account

Illustrative contract

Preview the intended integration boundary.

This shape documents the intended account and resource boundary. It is not callable, and it does not generate provider traffic.

Explicit connected-account ownership
Stable public resource identifiers
Truthful provider outcome state
Release status beside every capability

Illustrative shapePlanned · not callable

const unreleasedContract = {
  resource: "message",
  account_id: "acc_example",
  provider: "target_provider",
  availability: "not_implemented"
} as const;

No live connector · no provider request

Questions

Before you build.

Does DewEngine decide whether an AI agent may contact someone?+

No. The agent product must establish purpose, consent, recipient eligibility, and workflow policy. DewEngine's planned layer would enforce the delegated technical boundary and execute only a separately released provider capability.

Would MCP access let an agent bypass human approval?+

No by design. MCP would map to the same authorization and command services as REST. The application can require an immutable approval receipt for a write, and missing or stale approval should fail closed.

Build with us

Does this match the workflow your users need?

DewEngine is in development. Real use cases decide what ships first.

Share your use case ↗