Most agent knowledge problems are not about retrieval quality. They are about scope.

An agent writes to the wrong record because it had access to the wrong namespace. A support agent overwrites a ticket it only needed to read. A production agent touches test data because access was not scoped per deployment.

Once agents start reading and writing real operational data, scope becomes a production requirement.

Knowledge scope is not the same as prompt context

Prompt context is what you put in the system message. Knowledge scope is what the agent is allowed to access at runtime.

These are different concerns.

An agent might have instructions to “only touch this customer’s tickets.” But if the runtime gives it broader access, the agent can still read or overwrite data it shouldn’t.

Scope must be enforced at the infrastructure layer, not in the prompt.

Scope needs to be explicit per run

Different runs need different data access.

A support agent handling one ticket should only access:

  • The namespace holding that ticket
  • Keys matching that specific ticket or account
  • Read-write where it needs to update status, read-only everywhere else

An internal operations agent might need:

  • Broader read access across multiple namespaces
  • Write access scoped to its own working namespace

This is not something the agent should decide. It’s frozen at run creation.

sypho freezes knowledge scope at run time

When you create a run on sypho, the manifest declares:

Namespaces — Which structured-data namespaces the agent depends on

Keys — Which keys or key patterns within each namespace

Permissions — Read-only or read-write access per namespace

A run creator can narrow this further — never widen it — for a specific run.

This scope is fixed for the lifetime of the run. The agent cannot escape it.

Why this matters for debugging and audit

Data access is a common thing teams need to answer for:

  • Which records did this agent read or write during this run?
  • Was the agent allowed to touch this namespace?
  • Did the agent have write access, or only read?
  • Can you prove the agent did not touch out-of-scope data?

With scoped structured data, the answer is always yes.

Every access is recorded alongside the tool call that made it.

sypho makes knowledge scope a deployment primitive

On sypho, knowledge scope is not a feature bolted on top. It’s how agents access data at all.

Every manifest declares:

structured_data:
  tickets:
    required: true
    default_permission: read_write
    keys:
      - "ticket:*"
  playbooks:
    required: false
    default_permission: read

This scope is validated on every structured_data_get, structured_data_save, and structured_data_query call the agent makes.

Need scoped, versioned data access for production agents? Join the sypho waitlist to get early access.