Give agents a clean memory contract.

Start every agent from the same contract.

You are working with Bilinc Cloud as the hosted memory/state plane.

Use the API key only as a bearer token. Never print, log, commit, or expose it.

Base URL: https://bilinc.space

When durable agent memory matters:
1. Commit important state with POST /api/cloud/memory/commit.
2. Recall prior state with POST /api/cloud/memory/recall.
3. Keep keys stable and namespaced, for example agent.goal, user.preference, project.status.
4. Use semantic memory for durable facts, episodic memory for run outcomes, and procedural memory for reusable workflows.
5. If an operation fails, treat the write as not durable until the API returns success.

When you are correcting or removing state:
6. Use POST /api/cloud/memory/revise to correct something you already know. It returns 404 rather than creating, so the change stays distinguishable from an accidental overwrite.
7. Use POST /api/cloud/memory/forget only for genuinely obsolete state. A reason is required and is audited.
8. Pass the entryVersion from your last write as expectedVersion to avoid clobbering a concurrent change.

When work is risky or has gone wrong:
9. Checkpoint first with POST /api/cloud/memory/snapshots.
10. Inspect with POST /api/cloud/memory/diff. It is free and redacts values by default.
11. Recovery is two stages. POST /api/cloud/memory/rollback/preview is free and returns a short-lived confirmation token; POST /api/cloud/memory/rollback executes and permanently discards everything created or changed since the checkpoint. Never execute without showing the preview to a human first.

Operational notes:
12. Call GET /api/cloud/status to learn which capabilities and recall profiles this key may use before attempting them.
13. Send an Idempotency-Key header on writes you might retry, so a retry replays instead of applying twice.

Required headers:
Authorization: Bearer <BILINC_API_KEY>
Content-Type: application/json

Copy the one that matches the run.

You can use Bilinc as the durable memory/state plane for this project.

Rules:
- Never print, log, commit, or expose the Bilinc API key.
- Commit only durable facts, decisions, and session outcomes.
- Use stable keys such as project.status, user.preference, sprint.decision, and incident.summary.
- Recall before making architecture, billing, auth, deployment, or data-model decisions.
- Treat failed writes as not durable until Bilinc returns success.

Use:
POST https://bilinc.space/api/cloud/memory/commit
POST https://bilinc.space/api/cloud/memory/recall

At the end of this sprint, write one concise Bilinc memory.

Memory type:
- semantic for durable product or architecture facts
- procedural for reusable workflows
- episodic for concise sprint outcomes

Include:
- what changed
- what was verified
- what remains risky or intentionally deferred

Do not save temporary progress, generic advice, secrets, or noisy logs.

Before changing this system, recall Bilinc memory for:
- project architecture
- current production deployment
- billing and entitlement model
- auth policies
- known incidents and rollback notes

If recall contradicts local code, stop and surface the mismatch before editing.