Agents use the same Kival knowledge model as people. They read objects and history, follow context, participate in discussions, and — when explicitly authorized — create or update shared knowledge.
The important question is not whether an agent can write to Kival, but what kind of contribution should become durable organizational knowledge.
Start by letting the agent explore
A read-only agent can search a workspace, inspect objects and versions, follow relationships and backlinks, and build context without changing shared state.
This is a useful first step when introducing an agent to a real workspace. It lets you evaluate what the agent retrieves and how it reasons over Kival's structure before giving it write authority.
Credential setup and scopes are covered in Agent access.
Let agents contribute synthesis
Agents are most useful when they turn scattered context into something durable: a research synthesis, an updated project brief, a draft runbook, a summary of a decision, or a maintained knowledge object.
Avoid filling Kival with generated copies of material that already exists elsewhere. The goal is not to preserve every model output; it is to preserve knowledge worth sharing and revisiting.
Update stable knowledge when the subject is the same
When an object already represents the thing being maintained, prefer updating that object over creating a new copy on every run.
Kival's immutable versions retain the earlier states. An agent can therefore keep a durable object current without erasing what people or previous runs wrote before it.
If the new material needs an independent history, access boundary, discussion, or set of relationships, create a separate object instead.
Use discussion for uncertain contributions
An agent does not always need to edit canonical content immediately. It can participate in object commentary when the useful contribution is a question, review, proposed correction, or interpretation that a person should consider first.
When that discussion produces a durable conclusion, update the object itself. The same boundary applies to human collaboration: comments are working context; versions are canonical authored knowledge.
Choose an interface that fits the agent
The CLI is useful for tool-using agents because it exposes discoverable commands and structured JSON output. The HTTP API and official SDKs are better when Kival is embedded directly into an application or agent runtime.
All three interfaces operate on the same server-side model. Choosing one does not change the semantics of objects, versions, access, or provenance.
Keep contributions inspectable
Agent-created versions are attributed through the user whose API key performed the action, while audit events can also retain the specific API-key context. That makes separate agent or integration credentials useful even when they ultimately act through the same human authority.
Write objects so another person can understand what the agent concluded and, where relevant, what evidence or source material it used. Kival can preserve explicit provenance, but it cannot infer lineage that was never represented.
Keep authority narrower than capability
A capable agent does not need broad credentials. Give it access to the workspaces and operations required for its task, then expand that boundary only when the use case proves it needs more.
This keeps experimentation cheap: an early agent can begin as a reader, graduate to discussion or targeted writes, and only receive broader authority when the surrounding workflow justifies it.