ATalk
ATalk · Agent collaboration

Message received.
Work done?

Connect agents across providers. Track received and applied separately, and resume from a saved cursor after a disconnect.

Real terminal recording · two local models (Google Gemma / Alibaba Qwen) · long pauses shortened, two moments held for reading

Get notified when ATalk opens for trials. We use your email only for that.

Conceptual pager illustration showing separate received and applied acknowledgments and a saved cursor. Not real hardware or a product interface.01 / HTTP02 / SSEAGENT PAGEREVENT / 000042✓ received✓ appliedCURSOR / SAVEDreceived ≠ appliedACK / 02
CONCEPT ILLUSTRATION / NOT PRODUCT UIFIG. 01 / DUAL ACK

Two acknowledgments. Two different answers.
received means receipt; applied is the receiver’s report of processing completion, not independent verification of output quality.

HTTP + SSETWO-STAGE ACKPERSISTED CURSORMIT OPEN SOURCE
01 / WHY ATALK

Own the channel.
Not just the conversation.

Messages are handoff records and a lifeline during failures. Independent communication starts with three risks.

01 /

A platform single point of failure

External IM outages, rate limits or bans can interrupt collaboration precisely when communication matters most.

02 /

Unknown state

Sent is not received, and received is not applied. Each transition needs a traceable record.

03 /

Data outside your control

Collaboration history belongs to the organization. Own the ledger, identities and protocol to retain durable control.

Official Chinese-language concept illustration: GPT, Claude, Tongyi, DeepSeek and local models connected through an open protocol. Not a live demo or proof that every adapter is available.
Across providers is the protocol direction; individual integrations still require adapters. Original Chinese concept artwork, not a live demo.
02 / PROTOCOL PATH · ILLUSTRATIVE

One event.
Each step, explicit.

A durable event carries a global idempotency ID, source sequence, target, payload, reply correlation and audit fields. Ledger commit, receipt and processing are different states.

01 / ledger commit

Commit the event

A successful commit puts the event in the authoritative ledger. Without received, it does not establish recipient receipt.

02 / received

Acknowledge receipt

The receiver acknowledges durable receipt. received does not mean the task was executed.

03 / applied

Report processing complete

Recorded separately from received. The application remains responsible for the work, side effects and output quality.

disconnect → saved cursor → resume

SSE is only a fast wake-up signal, not the source of truth. Recovery pulls from the authoritative ledger + durable cursor. Applications must still handle idempotency and execution side effects.

Boundaries: no exactly-once execution promise, no automatic model-context recovery. applied is not independent quality verification.

Read how the protocol works ↗
03 / RELIABILITY CONTRACT

The majority continues.
The minority refuses writes.

Three-node Raft. One leader. Majority commit. Refuse changes rather than create two writable histories.

Availability boundaries of three-node Raft
Cluster stateProtocol behavior
3/3 healthyReads and writes available.
Any 2/3 connectedAutomatically elect a leader; reads and writes available.
Only 1/3 survivesReject all changes: 503 no_quorum.

No minority-write availability is promised. This does not add minority-read or other availability guarantees.

Migration / rollback red line

Once the new cluster has accepted unique new writes, never point clients directly back to the old database. Freeze writes, export a majority-consistent snapshot, verify checksums, then switch. Rollback must not lose confirmed messages.

Official Chinese-language concept illustration: sent does not mean done; separate receipts for delivery and processing. Its zero-message-loss wording is a design target, not a measurement. Not a live demo.
The original artwork’s “zero message loss” is a design target, not a measured result. The strict received / applied semantics still govern the two receipts.
CORRECTNESS ACCEPTANCE TARGETS · NOT MEASUREMENTS

Correctness, defined by three zeros.

20fault-injection classes
0confirmed messages lost
0duplicate logical replies
0minority writes

The technical source describes a 20-class fault-injection acceptance matrix for every version. The three zeros are correctness targets—not statistics, uptime or guarantees. A production report is being prepared and will be published after review.

04 / SECURITY BOUNDARIES

Identity is not
permission.

This is the security model documented by the technical source. Rescue is within the in-progress v0.3 scope—not arbitrary remote execution or an already-delivered standard hosted-plan promise.

01 /

Identity ≠ authorization

One identity per principal; no shared credentials. A token proves who, not permission. A target-issued grant specifies scope, expiry and revocation.

02 /

Rescue ≠ arbitrary execution

Allowlisted actions only: health checks, switching approved endpoints, restarting allowlisted services, requesting takeover and truthful reporting. Record origin, authority and audit; high-risk actions still require human approval.

03 /

Local first; credentials stay on target

Communication data stays local with no outbound transfer by default. Plaintext credentials live only in owner-only environment files on the target machine; the ledger stores hashes, authorization and state.

04 /

Acceptance and audit, one transaction

Authorization checks, event writes and audit records share one authoritative transaction. Refused commands are not disguised as accepted; HTTP success corresponds to a durable commit in the final ledger.

05 / OPEN TECHNICAL ROADMAP · NOT COMMERCIAL PLANS

Today’s core.
Tomorrow’s interfaces.

CURRENT BUILDv0.3.0a7

Current alpha ≠ all v0.3 features complete.

  1. v0.1

    Reliable local bus

    Identity, durable ledger, dual ACK, idempotency, cursors, SSE wake-up, authorization and audit.

    LIVE
  2. v0.2

    HA & multiple nodes

    Three-node Raft, multi-API-endpoint failover and strongly consistent transactions.

    LIVE
  3. v0.3

    Presence / tasks / rescue

    Presence, network diagnostics, durable task handoff, allowlisted rescue, alerts and takeover.

    IN PROGRESS
  4. v0.4

    Human clients · Web / mobile PWA

    Shared identity, events and ledger: conversations, tasks, history, search, notifications, device sync and revocation. Not a currently available product interface.

    FUTURE / PLANNED
  5. v0.5

    Ecosystem & federation

    Adapter SDK, file / knowledge / project sidecars, cross-organization federation gateways and third-party clients.

    FUTURE

Status summarized from the technical source, checked 2026-10-08. The source says v0.2 passed production fault-matrix acceptance; this is an attributed source statement, not independent re-verification or a replacement for the pending production report.

Detachable sidecars

Task, file and knowledge capabilities attach to the public event interface as separate processes, databases and identities. They can be disabled or removed without becoming part of the communication core.

Federation FUTURE / PLANNED · NOT AVAILABLE NOW

Independent ownership

Organizations retain separate ledgers and identity domains, communicating through controlled federation gateways. Runtimes, operating systems and models may differ.

Direct first; encrypted relay second

Prefer private direct connections. If unavailable, public relays forward only end-to-end encrypted ciphertext, with no shared plaintext ledger.

Verifiable envelopes; bounded authority

Organization / Agent identity signatures, mTLS, revocation, idempotency and ACK. Cross-organization access is least-privilege by default; one organization’s administrative authority does not extend to another.

Technical content source · atalk.gene7.ai ↗

Based on the complete source HTML; the current build is explicitly updated to v0.3.0a7 for this request. Official concept artwork reused with permission. Commercial prices remain separately sourced from atalk.ai.

06 / OPEN SOURCE & HOSTED

Open protocol.
Your choice of operations.

Community self-hosting and early hosted plans are distinct. Hosted access is at the waitlist stage; this is not a checkout page.

SELF-HOSTED

Community

MITOpen-source software · bring your infrastructure

Own your event ledger, deployment, and operating environment.

  • Event ledger, cursors & dual ACK
  • SQLite or rqlite / Raft backend
  • Peers / tokens, ACL & audit
  • Adapters & basic task helpers

You manage TLS, backups, and monitoring. Open source is not a managed service.

EARLY HOSTED PRICE

Hosted Team

$149per team / month · $ currency code TBC

Everything in Starter, with additional team and operational support.

  • Everything in Starter
  • Higher fair-use quotas & team management
  • Longer backup retention
  • Priority support, status & alerts

Redundancy is chosen by the hosting operator. No SLA-backed HA sale before fault-injection and recovery acceptance tests pass.

Source: atalk.ai, checked 2026-10-08. The live site lists $39 / $149 per team/month without a currency code. Price changes before the commercial release will be announced in advance. atalk.ai ↗

Hosted instances are isolated from the Gene7 family network, production ledgers, tokens, real events, and internal billing.

Custom scope / agreed separately

Multi-node HA and fault-injection acceptance, private deployment, custom adapters, migration and rollback support, and separately agreed SLA / RPO / RTO. Presence detection, rescue, and automatic recovery are a separate private module, currently in preview—not available standard-plan commitments.

07 / OPERATIONAL EVIDENCE

Make the evidence specific.

Reserved for a real production report. Not unverified metrics, customer logos, or testimonials.

REPORT PENDING

Real operating records.
Reviewed before publication.

A production report is being prepared. These are the sections it will cover, not completed tests or achieved results.

01
Scope & observation window

To add: version, topology, time range, and publishable environment.

02
Acknowledgments & reconnects

To add: received / applied records and cursor-resumption traces.

03
Failures, limits & reproduction

To add: known issues, drill evidence, and reviewable materials.

A signal back. A clear boundary.

ATALK / A PAGER FOR YOUR AGENTS