everos-cloud 1.1.0 — knowledge bases, async tasks, memory tags

The first feature release since 1.0.0. It opens three surfaces the SDK could not reach before — knowledge bases, async tasks and memory tags — and it is the release where every operation and every field finally carries a description.

Knowledge bases

A searchable document library with its own category taxonomy. Ingest is asynchronous, so the flow is ingest → wait → search:

from everos_cloud import EverOS

client = EverOS(api_key="sk-...")

kb   = client.kb_create("Employee Handbook", description="HR policies")
ack  = client.doc_ingest(kb.id, "Leave policy", "Employees accrue 20 days...")
task = client.task_wait(ack.task_id, timeout=300)   # polls until queryable

hits = client.kb_search(kb.id, "how much leave do I get", top_k=5)

kb_create / kb_list / kb_get / kb_update / kb_delete / kb_search, doc_ingest / doc_list / doc_get / doc_update / doc_delete, plus categories and topics through client.knowledge.

Async tasks

Every async write — a memory add, a document ingest — now reports through the task API. task_wait polls to a terminal state, backs off between polls, rides out a transient 429, and raises on failure or timeout:

task = client.task_get(task_id)
page = client.task_list(status="failed")
task = client.task_wait(task_id, raise_on_failure=False)   # inspect instead of raising

Memory tags

tag_bind / tag_unbind / tag_replace, scoped by memory id rather than by app or project. Tags are created by use — binding a name that does not exist yet is how it comes into existence.

Everything is documented

The contract shipped 3 operation descriptions out of 31, and 327 of its 421 schema properties carried only a generated label restating the field name (session_id → "Session Id"). This release fills all of it in: 34/34 operations and 481/481 properties. Those strings are the SDK's method docstrings and model attribute docs, so this is what your editor shows on hover.

The descriptions include the rules that live in server-side validators and were therefore invisible in the contract — you could not have discovered them without a 422:

• exactly one of user_id / agent_id is required on search and get, and memory_type must match that owner (a user owns episodes and profiles; an agent owns cases and skills);
• delete needs at least one scope — an empty body is rejected, not a full wipe;
• timestamp on a message is unix milliseconds; a seconds-scale value is rejected rather than silently rescaled;
• the batch caps: 1–500 messages per add, 1–50 edit operations, tags 1–100 × ids 1–200, top_k either -1 or 1–100;
• a non-text content item carrying only base64 is skipped by the parse step — upload it and pass the object key as uri instead;
• deleting a category reassigns its documents to uncategorized rather than deleting them.

Breaking: Python 3.12 or newer

python_requires was declared in the packaging template and never passed to setup(), so 1.0.0 shipped with no Requires-Python metadata at all — pip installed it on any interpreter and you met a traceback instead of a clear message. That is fixed, and the floor is set to 3.12.

If you are on an older interpreter, pip install -U everos-cloud will now decline the upgrade and keep you on 1.0.0, with an explicit reason:

ERROR: Package 'everos-cloud' requires a different Python: 3.10.17 not in '>=3.12'

pydantic also gained the < 3 upper bound it was missing. The generated models are written against pydantic v2's API, so a 3.0 release would otherwise have broken fresh installs with no change on our side.

Compatibility

Nothing was removed or renamed. The 27 new operations are additive, and the nine methods 1.0.0 shipped — add / search / get / flush / edit / delete, presign / upload, close — keep their names and signatures. Everything added since carries its resource as a prefix (kb_, doc_, task_, tag_), so typing client.kb lists the knowledge-base surface; the two styles side by side are a consequence of that freeze, not a convention.

The generated clients are now client.memory, client.storage, client.knowledge and client.tasks — every operation is reachable there, including the ones the ergonomic facade does not wrap.

Worth knowing

• add is asynchronous by default. It returns status: "queued", and a flush issued immediately afterwards returns no_extraction because the write has not landed yet. Either write with async_mode=False or wait on the add's task before flushing.
• Search scores are not comparable across methods. The hybrid path returns a calibrated probability in 0–1 (which is what min_score filters on); keyword and vector pass the underlying store's own score through, and BM25 has no upper bound.
• Knowledge search scores are normalized per response, so score_threshold cuts a relative position rather than an absolute relevance bar — the best hit of any response sits near the top of the range no matter how weak the pool.

Full contract: openapi.json · Usage: quickstart.md