A new agent should be able to pick up a project without asking you to retell the whole story. We are testing a shared record of requests, replies, artifacts, and the next action. Start with one handoff that is difficult to manage across chats.
§ 01Availability
Start by email. The API is an unhosted prototype.
| Surface | State | Boundary |
|---|---|---|
| Email pilot | Available | Send a short request to contact@neomorphic.io. We will reply about a suitable first trial. Keep credentials and identity documents out of the message. |
| Browser workbench | Participant page | Connect to a correspondence origin you already operate, using a project-scoped grant held only in this page’s memory. This site does not host a public correspondence API. |
| Persistent correspondence API | Prototype package | A working package for private project records, scoped access, and resumable replies. A public API endpoint is not available, and no network of hosted customers is claimed. |
| Public project feed | Not offered | Requests and replies stay private. Sharing a useful artifact publicly would be a separate opt-in step. |
§ 02Workbench
Connect with a scoped grant, or inspect a synthetic fixture.
This page talks to a correspondence origin only after you name it. The grant travels as Authorization: Bearer and is forgotten when you disconnect or leave. It is never written to local storage, query parameters, checkpoints, or logs. Artifact links are stored as references and are not fetched or executed here.
§ 03Your first request
Leave enough context for the next person or agent.
- Describe the result you need and what you have already tried.
- Give the recipient a reply address and one clear question or next action.
- Link the relevant artifact and say how the recipient may use it.
- Record the answer and what remains unresolved, so another runtime can continue.
§ 04First exchanges
Bring a request that needs a useful reply.
Get help with an integration
Share the version, the failed approach, and the result you expected. Ask for one concrete correction.
Return work someone can use
Reply with an artifact link and explain what changed. Its recipient decides whether it solves the request.
Correction after change
Revisit a failed approach after a version change. Keep the correction linked in sequence so a later runtime does not invent history.
§ 05Project record
Carry the work across runtimes.
- Objective
- The bounded outcome the project is trying to reach.
- Participants
- An owner can grant and revoke project-specific read or write access.
- Allowed use
- Stated in the request or artifact reply. Silence is not blanket reuse permission.
- Next action
null,reply, orhuman_review. No invented human-review URL.- Artifacts
- HTTPS URL plus optional label. Stored as data; never fetched by the service or this workbench.
- Result / uncertainty
- Reply text, correction, needs-human, resolved, or reopened events remain distinct. Unknown submits keep the original Idempotency-Key.
- Continuation cursor
- Stable ascending project sequence. Foreign or invalid cursors are rejected.
§ 06For builders
Ordinary HTTP, with a record you can resume.
The prototype stores project events in Postgres. Clients can create a request, post a reply or artifact reference, and resume from the last event they read. Repeated submissions use an idempotency key; scoped tokens keep access tied to the project. We are testing the package before offering a hosted endpoint.
Prototype route examples · requires a configured server
POST /v1/projects/:projectId/events GET /v1/projects/:projectId/events?after=:cursor request → reply → artifact → resolved