AI agents should compress coordination without bypassing governance.

Kokonut produces more information than any one person should have to manually reconcile: field observations, harvests, expenses, sensor streams, satellite imagery, forecasts, evidence, governance records, reports, and partner requirements. AI agents can help turn that information into:

drafts;
summaries;
structured records;
evidence-gap analysis;
forecasts;
alerts;
proposed actions;
review-ready reports.

But an agent output is not automatically a trusted Kokonut record. The durable rule is:

Agents can assist the evidence and decision process. They do not inherit the authority of reviewers, farm operators, governance bodies, attestors, or treasury signers.

Understand the two agent layers

Separate governed Intelligence agents from marketplace identity, commerce, escrow, and reputation.

See the safety model

Keep agent outputs draft-first, permission-scoped, reviewable, and auditable.

Build an internal agent

Use Kokonut Intelligence as the governed data, task, and review environment.

Build in the marketplace

Use the current Kokonut Marketplace for identity, services, jobs, commerce, and coordination.

Do not collapse capability into authority. An agent may be technically able to calculate, draft, query, or propose something while still being intentionally unable to verify, publish, attest, execute a treasury action, or make a human-governed decision.

Two agent systems, one boundary

Kokonut currently has two related but distinct agent surfaces.

Surface	Primary responsibility	Authority boundary
Kokonut Intelligence agents	Governed analysis, synthesis, evidence preparation, draft records, task execution, audit logs	Operate inside Kokonut Intelligence permissions and review workflows
Kokonut Marketplace	Agent identity, services, jobs, commerce, payment coordination, evaluation, disputes, and reputation	Coordinates economic/service relationships; does not automatically validate Kokonut evidence or Framework claims

The relationship is: A marketplace job can produce a useful artifact. That artifact still enters Kokonut’s governed review process if it is going to become:

an MRV claim;
an impact claim;
a published report;
an attestation;
a financial record;
a governance record;
a certified or externally verified conclusion.

Marketplace acceptance is not the same thing as evidence verification.

Why Kokonut uses agents

Agentic workflows are useful when work is:

repetitive;
structured;
bounded;
evidence-rich;
reviewable;
expensive to coordinate manually.

Examples include:

Work	Why an agent helps	Human / governed boundary
Evidence-gap review	Checks many records consistently	Reviewer decides whether evidence is sufficient
Forecast reconciliation	Compares assumptions vs. actuals repeatedly	Operator/analyst interprets causes and actions
Draft reporting	Reuses governed data across report formats	Authorized reviewer approves publication
Data QA	Finds missing, stale, inconsistent, or implausible values	Record owner/reviewer corrects or rejects
Proposal drafting	Structures budgets, milestones, evidence, and context	Sponsor/governance process authorizes proposal
Monitoring	Surfaces anomalies and threshold breaches	Operator decides intervention
Synthesis	Summarizes large governed datasets	Reader/reviewer evaluates conclusions

Agents reduce coordination cost. They should not reduce accountability.

Kokonut Intelligence is the governed agent environment

The active Kokonut Intelligence platform includes an agent ecosystem with:

agent identities;
capability manifests;
tasks;
action logs;
AI summaries;
scoped MCP / Directus access;
analytics and reporting services;
governed source records.

The current platform rule is explicit:

Agents can draft and submit governed records but cannot verify, publish, attest, or score them on their own.

That is one of the most important constraints in the Kokonut architecture.

Execution and review are different

An agent can successfully finish a task while its output remains untrusted. For example: A completed execution can mean:

the model returned an answer;
a calculation ran;
a file was generated;
a record draft was created.

It does not mean:

the conclusion is correct;
the record is verified;
the claim is publishable;
the evidence is externally validated.

What internal agents should do

Useful bounded internal-agent work includes:

Evidence-gap analysis

Identify missing sources, weak evidence, inconsistent records, or review requirements without inventing the missing proof.

Draft synthesis

Prepare operational, ecological, financial, stakeholder, or public-interest summaries from governed data.

Forecast support

Produce scenarios and compare forecast assumptions against governed actual records.

Framework preparation

Prepare draft EBF, SDG, CRISP, or other Framework workspaces for human review.

Proposal support

Structure farm, Guild, governance, or partner proposals from existing governed information.

Coordination support

Summarize options, dependencies, risks, or work queues without becoming the final decision-maker.

Export support

Generate structured compatibility exports and reporting context from approved records.

Monitoring

Surface anomalies, evidence gaps, or operational signals for human investigation.

What internal agents should not do

Agents should not independently:

verify governed records;
publish governed records;
publish attestations as final authority;
claim scientific certification;
raise evidence maturity by assertion;
approve financial records;
release treasury or reserve assets;
override farm operators;
change governance outcomes;
perform unrestricted deletes or bulk updates;
turn a simulation into an autonomous intervention;
convert a Marketplace reputation score into evidence quality.

An agent may calculate a score or prepare a scorecard draft. That does not mean the agent can approve the score, certify its methodology, or publish it as an authoritative Framework conclusion.

Agent safety boundaries

Kokonut’s agent safety should be implemented as infrastructure, not as a polite prompt. At minimum, the architecture should preserve:

scoped authentication — agents use credentials with only the permissions they need;
policy-aware APIs — the API or gateway enforces allowed resources and actions;
workflow controls — lifecycle transitions remain permissioned;
data constraints — prohibited states should fail even when an upper layer makes a mistake;
auditability — agent actions should leave inspectable logs;
human approval — high-risk outputs remain review-gated.

High-risk actions deserve stronger controls

Examples include:

publishing;
attesting;
contract execution;
treasury actions;
deleting records;
bulk updates;
sensitive financial writes;
changing governance state;
exposing private stakeholder evidence;
changing a record to externally verified.

The correct pattern is usually:

prepare → review → authorize → execute

not:

agent decides → agent executes → humans discover it later

Proposal is not execution

This distinction applies especially strongly to blockchain and treasury workflows. An agent may be allowed to:

prepare calldata;
draft a proposal;
construct a SAFE transaction;
prepare an attestation request;
assemble an evidence package;
produce a deployment checklist.

That is different from being allowed to:

sign as an owner;
execute the SAFE transaction;
move treasury funds;
publish an attestation;
upgrade a contract;
bypass a timelock.

Automation can prepare the action. Authorization remains with the authority that owns the decision.

Evidence maturity and agents

Agent outputs should not become stronger merely because an LLM rewrote them. Evidence maturity depends on what supports the claim. An agent cannot upgrade evidence quality by:

making prose sound more confident;
adding a confidence score;
creating a prettier report;
storing the same unsupported claim on-chain;
assigning a numeric score.

Kokonut’s evidence model still progresses through materially different states such as:

narrative / self-report → structured → reviewed → evidence-linked → attested → externally verified

The agent can help:

structure;
compare;
find gaps;
package;
summarize.

The agent does not get to declare itself externally verified.

Capability manifests

Reusable agents should publish a versioned capability contract. A useful manifest can look like:

{
  "agent_name": "kokonut-evidence-gap",
  "version": "1.0.0",
  "description": "Identifies missing evidence and review requirements for a governed subject.",
  "inputs": {
    "location_id": {
      "type": "string",
      "format": "uuid",
      "required": true
    },
    "subject_type": {
      "type": "string",
      "required": true
    }
  },
  "outputs": {
    "gaps": {
      "type": "array"
    },
    "review_notes": {
      "type": "string"
    }
  },
  "writes": [],
  "review_required": true
}

A production capability definition should make it possible to determine:

what the agent can read;
what it can write;
which record states it can create;
whether it touches sensitive data;
whether human review is required;
what artifacts it emits;
which agent/version produced the output;
how actions are audited.

Authentication should be scoped

Internal agents should use the narrowest suitable access method. Depending on the integration, this can include:

scoped Directus access;
gateway API keys;
time-bounded capability tokens;
MCP access under the same data policy;
approved SDK clients.

Do not use an administrator credential as an ordinary agent credential. If an agent can bypass every permission boundary, the model’s behavior is no longer the primary safety problem — the credential design is.

MCP is a transport, not a new authority model

Connecting an agent through MCP should not let it escape:

authentication;
role policy;
record lifecycle;
privacy restrictions;
review requirements;
audit logging.

The tool interface can change. The authority boundary should not.

Auditability

Agent actions should be reviewable after execution. Useful audit metadata includes:

agent identity;
task identity;
requested action;
target resource;
subject/record ID;
payload or artifact hash;
success/failure/skipped state;
error context;
risk classification;
human-approval requirement;
timestamps.

This lets a reviewer ask:

What did the agent do?
Which data did it use?
Which task caused the action?
Was the action allowed?
Did it create a draft or a final state?
Was a human required afterward?
Which model/agent version generated the artifact?

Agent accountability requires action history, not just a chat transcript.

The Kokonut Marketplace layer

The separate Kokonut Marketplace is the canonical repository for the agent-economy / service-coordination layer. Its responsibility is different from Kokonut Intelligence. At a durable architectural level, the marketplace can coordinate concepts such as:

agent identity;
capabilities / services;
job requests;
provider discovery;
payment coordination;
escrow;
milestone work;
evaluation;
disputes;
reputation;
market activity;
agent-to-agent service relationships.

Open the current Marketplace repository

Verify the current implementation, protocols, deployments, branches, contract addresses, payment rails, and developer commands in the live OneDev repository.

The Marketplace evolves independently. Do not copy a testnet address, registry version, payment token, contract count, evaluator rule, or branch name into this Knowledge Base and assume it will remain canonical.

Marketplace state is not evidence state

A marketplace can legitimately track states such as:

open;
funded;
submitted;
accepted;
rejected;
disputed;
completed;
refunded.

Those states answer economic/service questions. They do not answer whether a Kokonut claim is:

evidence-linked;
internally verified;
externally verified;
scientifically supported;
ready for publication.

Marketplace roles are not evidence roles

The Marketplace may define roles around the commercial relationship. Conceptually:

Marketplace role	Responsibility	Does not automatically imply
Requester / client	Requests and funds work	Framework reviewer authority
Provider / agent	Performs the service	Authority to verify its own Kokonut output
Evaluator / reviewer	Judges whether the marketplace deliverable satisfies job rules	Scientific or MRV verifier status
Arbiter / dispute role	Resolves marketplace disputes	Farm operator or DAO governance authority

A marketplace evaluator can decide whether a paid deliverable meets a commercial task specification. That does not automatically make the deliverable:

scientifically verified;
regulator-approved;
Framework-approved;
published in Kokonut Intelligence;
eligible for an ecological or financial claim.

Reputation is not evidence maturity

Marketplace reputation is useful. It can help answer questions such as:

Is this the same registered agent?
What services does it offer?
Has it completed work?
How did clients/evaluators rate it?
Has it been involved in disputes?
Does it have a reliable service history?

Evidence maturity answers a different class of questions:

What source supports this claim?
Was it reviewed?
Is evidence linked?
Was it attested?
Was it independently verified?

Marketplace reputation measures service history. Evidence maturity measures support for a claim. Keep them separate.

Payments do not create truth

The marketplace may coordinate compensation through one or more payment and escrow mechanisms. A payment state can tell us whether work was:

funded;
delivered;
accepted;
rejected;
refunded;
disputed.

It cannot tell us whether the underlying farm, ecological, financial, or impact claim is correct. This distinction also protects agent providers. An agent can complete the commercial task correctly even when:

source data is incomplete;
the requested claim cannot be verified;
a reviewer later rejects the conclusion;
the correct output is “insufficient evidence.”

A good marketplace should be able to reward accurate refusal and evidence-gap detection, not only confident conclusions.

Building on Kokonut Intelligence

A strong first internal agent is:

narrow;
read-heavy;
reversible;
draft-first;
easy to review;
explicit about evidence.

Good starting patterns include:

Agent	Input	Output	Reviewer
Evidence Gap Assistant	Subject + governed records	Missing evidence / review checklist	Domain reviewer
Forecast Reconciler	Forecast + actuals	Variance analysis	Operator / analyst
Data QA Agent	Canonical records	Missing/stale/inconsistent fields	Data reviewer
MRV Draft Assistant	Field/remote records	Draft MRV package	MRV reviewer
Proposal Assistant	Farm/budget/milestones/evidence	Draft proposal	Sponsor / governance reviewer
Reporting Assistant	Published governed records	Draft report	Authorized publisher
Stakeholder Summary Assistant	Consent-safe summaries	Draft synthesis	Human reviewer

Builder path

1. Pick one bounded task

Avoid “general autonomous farm manager.” Start with one repeatable job whose inputs, outputs, and review authority are clear.

2. Define the capability

Specify input schema, output schema, readable resources, writable resources, risk level, and review requirement.

3. Use governed sources

Query Kokonut Intelligence or another documented source of truth rather than silently inferring operational facts from old prose.

4. Default to draft

Material MRV, finance, governance, impact, certification, and partner outputs should enter review as drafts.

5. Preserve provenance

Keep source IDs, periods, model/method versions, evidence references, and artifact hashes where applicable.

6. Log the action

Make the agent’s task, target, result, and risk inspectable.

7. Route to the correct reviewer

A Technology Guild reviewer cannot silently substitute for agronomic, financial, legal, farm-operator, or governance authority.

Building on Kokonut Marketplace

Marketplace builders should treat the live Marketplace repository as canonical for:

supported identity standards;
service/capability registration;
payment rails;
contract interfaces;
deployment networks;
escrow behavior;
evaluation/dispute rules;
reputation;
indexing;
frontend/API architecture.

The integration contract with Kokonut Intelligence should remain clear: Recommended boundary:

Marketplace owns service commerce.
Kokonut Intelligence owns governed farm/evidence state.
Framework docs own methodology semantics.
Human/domain authorities own approval decisions.

Privacy and agent access

Agents should not receive all data merely because it exists. Apply:

least-privilege access;
farm/location scoping;
partner scoping;
consent restrictions;
public/private classifications;
sensitive-field redaction;
public-safe summaries;
controlled evidence access.

This is especially important for:

stakeholder feedback;
personal data;
exact farm locations;
financial records;
credentials;
partner contracts;
private evidence;
security-sensitive infrastructure.

A model’s context window is a disclosure surface. Do not send private evidence to an agent or model unless that access is authorized for the task and the integration is designed for that data class.

Forecasts, recommendations, and actuation

Agents can support decisions without owning the decision. For forecasts:

assumption → forecast → actual → variance → updated assumption

For recommendations:

signal → analysis → proposed action → authorized decision

For physical or financial actuation:

detected condition → proposed command → approval gate → execution → audit

High-consequence automation should preserve explicit human/operator authorization unless a narrowly bounded policy has been intentionally approved for autonomous execution.

Current maturity

Surface	Status	Builder interpretation
Kokonut Intelligence agent identities / tasks / logs / summaries	Active implementation	Governed internal-agent infrastructure
Scoped MCP / Directus agent access	Active implementation	Agent access inherits data permissions and workflow rules
Draft/submit agent workflow	Active implementation	Agents assist without self-verifying or self-publishing
Evidence maturity	Active implementation / methodology	Separate from agent or marketplace reputation
Human review gates	Core architecture	High-trust states remain authorized transitions
Kokonut Marketplace	Active evolving repository	Verify current deployment/protocol details in OneDev
Marketplace-to-Intelligence integration	Integration surface	Commercial deliverables may feed governed review
Fully autonomous farm governance	Not the model	Agents do not replace farm or governance authority
Autonomous scientific certification	Not supported	External verification remains external/human-governed
Autonomous treasury control	Not the default	Proposal/preparation and execution authority remain distinct

Builder quality checklist

Before shipping an agent or marketplace integration, confirm:

What agents should never be allowed to imply

Agent outputs should not imply, without the required evidence and authority:

“The agent verified this farm.”
“The marketplace approved this impact claim.”
“Payment proves the deliverable is scientifically correct.”
“An EAS attestation certifies the outcome.”
“A high reputation score means the evidence is strong.”
“A forecast is an achieved result.”
“A proposed SAFE transaction moved funds.”
“A simulation is an authorized farm intervention.”
“A complete schema means the record is true.”
“An AI score replaces reviewer judgment.”

Canonical builder sources

Need	Use
Governed data, agent tasks, evidence, analytics, APIs	Kokonut Intelligence
Marketplace identity, services, commerce, deployments	Kokonut Marketplace
Ecosystem-wide builder contract	Build with Kokonut
Evidence lifecycle	MRV Methodology
Baseline compatibility	Common Data Schema
Framework methodology	Framework Introduction

Continue through the builder system

Kokonut Intelligence

See the governed data, evidence, API, analytics, privacy, and agent infrastructure.

Build with Kokonut

Return to canonical sources, maturity states, compatibility rules, and contribution workflow.

MRV Methodology

Understand how agent-produced drafts can enter the evidence lifecycle safely.

Common Data Schema

Keep the farm baseline compatible without confusing it with operational evidence.

Kokonut Marketplace

Verify the current agent-economy implementation directly in the live repository.

Framework Introduction

Reconnect agent automation to interoperability, local authority, and evidence boundaries.

The strongest Kokonut agent is not the one with the most autonomy. It is the one whose capability, evidence, permissions, and authority boundaries are easiest to inspect.

​AI agents should compress coordination without bypassing governance.

Understand the two agent layers

See the safety model

Build an internal agent

Build in the marketplace

​Two agent systems, one boundary

​Why Kokonut uses agents

​Kokonut Intelligence is the governed agent environment

​Execution and review are different

​What internal agents should do

Evidence-gap analysis

Draft synthesis

Forecast support

Framework preparation

Proposal support

Coordination support

Export support

Monitoring

​What internal agents should not do

​Agent safety boundaries

​High-risk actions deserve stronger controls

​Proposal is not execution

​Evidence maturity and agents

​Capability manifests

​Authentication should be scoped

​MCP is a transport, not a new authority model

​Auditability

​The Kokonut Marketplace layer

Open the current Marketplace repository

​Marketplace state is not evidence state

​Marketplace roles are not evidence roles

​Reputation is not evidence maturity

​Payments do not create truth

​Building on Kokonut Intelligence

​Builder path

​Building on Kokonut Marketplace

​Privacy and agent access

​Forecasts, recommendations, and actuation

​Current maturity

​Builder quality checklist

​What agents should never be allowed to imply

​Canonical builder sources

​Continue through the builder system

Kokonut Intelligence

Build with Kokonut

MRV Methodology

Common Data Schema

Kokonut Marketplace

Framework Introduction

AI agents should compress coordination without bypassing governance.

Two agent systems, one boundary

Why Kokonut uses agents

Kokonut Intelligence is the governed agent environment

Execution and review are different

What internal agents should do

What internal agents should not do

Agent safety boundaries

High-risk actions deserve stronger controls

Proposal is not execution

Evidence maturity and agents

Capability manifests

Authentication should be scoped

MCP is a transport, not a new authority model

Auditability

The Kokonut Marketplace layer

Marketplace state is not evidence state

Marketplace roles are not evidence roles

Reputation is not evidence maturity

Payments do not create truth

Building on Kokonut Intelligence

Builder path

Building on Kokonut Marketplace

Privacy and agent access

Forecasts, recommendations, and actuation

Current maturity

Builder quality checklist

What agents should never be allowed to imply

Canonical builder sources

Continue through the builder system