Skip to content
ChuskyChusky changelog

What changed.
What it means.

A running record of product updates across the agent, connected apps, missions, and developer platform. We focus on user-visible changes; routine maintenance commits may not appear here.

Start for Free Sign in

  1. Attention Pulse · Elena · TypeScript SDK 1.10.0

    Elena can turn connected-app signals into next actions

    Attention Pulse now gives Chusky a durable proactive loop that checks owner-scoped signals, prepares useful work, and reports exactly what needs the owner’s attention.

    • Elena’s hourly pulse can inspect bounded signals from connected apps, calendars, billing, work, artifacts, tasks, approvals, and failed automations instead of waking up without an actionable operating context.
    • Pulse observations are deduplicated, account-scoped, and delivered through the owner’s explicitly selected channels. Every update distinguishes a verified observation, a prepared draft or plan, an approval request, and work that is blocked or awaiting a connection.
    • Owners can configure the pulse during onboarding or later through the dashboard and API: enablement, cadence, authority, quiet hours, daily delivery limits, monitored domains, and Telegram, dashboard, or linked-channel delivery preferences.
    • Elena can prepare replies, follow-ups, summaries, reminders, and other reversible next steps for review. Financial, destructive, permission-changing, and otherwise high-impact actions remain behind the existing approval boundary.
    • TypeScript SDK 1.10.0 adds typed Attention Pulse settings and the authenticated GET/PUT API contract, with idempotent updates, validation, OpenAPI documentation, and regression coverage.

  2. Meetings · Dashboard and TypeScript SDK 1.9.1

    Meeting workspaces can stay in sync live

    The dashboard and TypeScript SDK can receive owner- and workspace-scoped meeting updates over a live event stream.

    • The SDK exposes typed meeting snapshot and keepalive events and supports caller cancellation for the stream.
    • Workspace membership is checked by the API before streaming; meeting details remain scoped to the authenticated owner or workspace.
    • The SDK 1.9.1 release adds the stream client, API contract and OpenAPI updates, tests, and rebuilt package files.

  3. Missions · Recovery and approvals

    Expired mission time now becomes a real approval

    A mission that needs more execution time pauses the same durable mission and puts an exact, bounded resume action in the owner’s approval queue.

    • Chusky no longer asks for a duration extension as plain assistant text. The saved approval contains the mission ID and exact proposed duration, and it is deduplicated across worker retries.
    • Approving resumes the original mission task exactly once and preserves the existing checkpoint, evidence, step, tool, spend, and account boundaries.
    • The dashboard shows the approval even when the original chat run is idle, so the owner can approve or deny it without hunting through an old message.

  4. Missions · Timing and approval recovery · SDK 1.9.0

    Mission execution time pauses while work waits

    New missions track active execution separately from their overall deadline, while approved resume actions update the original chat activity with their saved result.

    • Waiting, paused, blocked, and approval-held time no longer consumes the active execution budget of new missions. Existing missions retain their original wall-clock timing contract.
    • Automatic extensions require an owner-authorized allowance and new trusted completed-step progress. They cannot reset spend, tool-call limits, permissions, or the overall deadline.
    • Approved mission resume executes the exact stored arguments without another model decision. The original activity shows execution success, failure, or denial and remains accurate after refresh.
    • If an approval response is lost, the dashboard checks the saved approval and run before offering retry. Approval acceptance is not presented as proof that the mission completed.
    • SDK 1.9.0 exposes the new mission timing settings and persisted extension usage, with updated API and mission documentation.

  5. Missions · Change lock and verification

    Mission changes now require trusted proof

    Strict mission verification now binds each receipt, artifact, or human confirmation to trusted evidence owned by that mission before the outcome can be closed.

    • Receipt, artifact, and human checks can reference an exact persisted evidence record; descriptions and model-authored pass results are never treated as proof.
    • Evidence is checked against the current owner and mission, including its kind, source, reference, and verification authority, so another mission or account cannot satisfy the check.
    • Provider-read checks still execute a fresh read-only action and compare the returned state. Turning a change into a completed mission requires the recorded proof, not only a checkpoint or optimistic response.

  6. Developer platform · TypeScript SDK

    The TypeScript SDK now works without API URL setup

    Hosted SDK applications can connect with their API key and user ID while Chusky handles the API address internally.

    • New SDK clients can start with only an API key and a stable user ID; no base URL environment variable is required.
    • The quickstart, cookbook, API contract, and OpenAPI documentation now focus on creating an API key in the Chusky dashboard.
    • SDK version 1.7.1 includes the updated default, a regression test, and rebuilt distribution files.

  7. Agent · Decision routing

    Chusky now finds the right connected app faster

    Jev now helps Chusky route requests across skills, Composio apps, actions, and Treg endpoints while preserving deterministic fallbacks and approval rules.

    • Connected apps are ranked by the user's request and the most suitable action is selected from the provider catalogue, so Gmail requests can reach Gmail actions directly.
    • If a request names an app that is not connected, Chusky identifies it, presents the connection path, and keeps that app's actions unavailable until the account is connected.
    • Routing runs inside a shared deadline and falls back to the existing deterministic routes; Jev never grants approval or overrides budgets, account isolation, or native tool policy.

  8. Agent · Private owner context

    Your private agent can carry more of your context into calls and meetings

    Private owner conversations can use relevant account history and connected tools across chat, phone, and meeting work, for both personal and business tasks.

    • Authenticated dashboard chat, CLI, Telegram, verified private calls, and private meeting-representative runs use the same owner-scoped context and durable continuation path.
    • Shared rooms and project/API-key runs keep their separate tool and privacy policies; they do not inherit an owner's private context.
    • Routine owner-directed work can proceed directly. Deletion and other high-impact actions still pause for the required approval.

  9. Developer platform · Generated images

    Generated images are available to API and SDK clients

    Completed runs include metadata for generated images saved to the owner's private image store, and the dashboard can render those previews.

    • The SDK can request a fresh, short-lived download URL through an owner-scoped endpoint; project keys need images:read.
    • Image bytes, object-storage keys, and signed URLs are not stored in run records. The web client refreshes the link when it loads the image.

  10. Slack · Media delivery

    Slack replies can include generated images and files

    Chusky can deliver supported generated media in Slack replies using Slack's current external file-upload flow.

    • Media is staged from the linked owner's private storage and uploaded directly to the selected Slack conversation or thread.
    • The Slack app needs the files:write permission; existing installations may need to be re-authorized after that permission is added.
    • Delivery is confirmed from Slack's file receipt. If completion is uncertain, Chusky records the ambiguity instead of blindly uploading again.

  11. Operations · Verification

    Provider readiness requires evidence for each capability

    A configured integration is no longer mistaken for a proven one, and a single generic smoke check cannot certify every channel and media path.

    • Signed provider reports must include fresh, separate inbound-text, inbound-image, outbound-text, and outbound-image observations.
    • Each observation is tied to a hashed provider event or receipt identifier; raw identifiers and payloads are not stored in the proof record.
    • Incomplete or expired reports remain unverified. This contract does not itself claim that a live provider test has passed.
    • Operators can run a staging-only signed-webhook boundary check without sending messages or changing readiness; it does not certify inbound message handling, media, or delivery.

  12. Missions · Replay

    Mission replay keeps approval history exact

    Replaying a mission now matches approval waits and resumptions by their persisted approval ID, rather than by similar-looking event text.

    • New lifecycle events retain the approval identity needed to reconstruct the exact wait-and-resume sequence.
    • Older or incomplete history is reported as incomplete instead of being guessed into a successful replay.
    • This makes mission timelines and recovery decisions more dependable without changing who can approve an action.

  13. Missions · Recovery

    Mission recovery now checks the result

    A recovery action is not treated as done just because a provider accepted a request.

    • Consequential compensation runs against the exact connected-app action covered by an unexpired owner approval.
    • Chusky stores the external receipt and performs a fresh provider read-back against the expected state before marking recovery successful.
    • If the provider outcome is uncertain, the mission reconciles its state instead of blindly sending the same write again.

  14. Images · Connected apps

    Images can move from chat into app workflows

    Use an image already in the conversation, a generated image, or a saved asset in supported Gmail, Facebook, LinkedIn, and other connected-app actions.

    • Chusky matches each action's current input schema and handles legacy LinkedIn media-action shapes; availability depends on the connected account and its available actions.
    • Image bytes and signed URLs stay on the trusted server, and separate upload and publish steps remain distinct when a provider requires them.

  15. Missions · Verification

    Mission outcomes can be checked against provider state

    Supported outcome checks now use an exact read-only action from the owner's connected-app session.

    • Fresh provider observations are redacted, timestamped, and linked to mission evidence.
    • A model-generated summary or caller-supplied pass result is not enough to close a strict mission.

  16. Operations · Reliability

    A clearer view of receipts, verification, and readiness

    The operator reliability surfaces bring mission timelines and provider evidence into an owner-scoped view.

    • Inspect external-action receipts, outcome verification, delivery recovery, and provider-proof status together.
    • Configured providers are not automatically presented as certified; missing or stale proof remains visible as unverified.

  17. Integrations · MCP

    Third-party MCP servers are checked before they are saved

    Connections now verify discovery before becoming available to the agent.

    • The integration supports Streamable HTTP and a legacy HTTP+SSE fallback, with bounded tool schemas and results.
    • Credentials stay encrypted on the trusted backend, and private-network destinations and redirects are rejected.

  18. Autonomy · Dashboard

    Long-running work is easier to inspect and recover

    The autonomy workspace brings queued work, blockers, watches, and recovery status into one account-scoped view.

    • Mission and task state can be inspected without presenting a checkpoint as a completed outcome.
    • Delivery recovery records ambiguous sends for owner review rather than automatically replaying a possibly completed action.

  19. Developer platform · API and SDK

    More durable workflow controls are available to developers

    The API and SDK cover owner-scoped autonomy queues and dependency-aware workflow composition.

    • Build parallel-ready stages, retry and budget controls, and approval checkpoints into durable workflows.
    • The same authenticated identity, ownership, and approval boundaries apply across API clients.

  20. Developer platform · A2A

    External agents can discover and track durable tasks

    The A2A surface includes discovery and task lifecycle operations, with the same owner-scoped durable execution model.

    • Clients can create, inspect, paginate, and cancel supported tasks through the documented contract.
    • Task status and completion remain backed by Chusky's persisted lifecycle rather than a disconnected chat response.

See the product in action

Explore the capabilities and developer surfaces behind these updates.

Features Developers