Skip to content

Add agent implementation scaffold and feasibility review#17

Open
glandua wants to merge 5 commits intoregen-network:mainfrom
glandua:claude/agentic-tokenomics-feature-4mUuJ
Open

Add agent implementation scaffold and feasibility review#17
glandua wants to merge 5 commits intoregen-network:mainfrom
glandua:claude/agentic-tokenomics-feature-4mUuJ

Conversation

@glandua
Copy link
Contributor

@glandua glandua commented Feb 13, 2026

Summary

This PR adds a working agent implementation scaffold for the Regen Agentic Tokenomics framework, along with comprehensive feasibility and voice memo analysis documents. It bridges the gap between specification (Phases 1-3) and runnable code by providing:

  1. Two reference agent implementations (Registry Reviewer, Governance Analyst) as ElizaOS characters
  2. Core OODA loop executor for workflow orchestration
  3. MCP client libraries for Ledger and KOI knowledge graph access
  4. Test suite covering workflow execution, proposal analysis, and client behavior
  5. Local development environment (Docker Compose, database schema, config loader)

Key Changes

Documentation

  • FEASIBILITY-REVIEW.md: Comprehensive assessment of the framework's viability as a project management system for agent swarms. Identifies specification-reality gap as the primary risk and recommends phased deployment starting with the Governance Analyst agent (Layer 1, informational only).
  • VOICE-MEMO-ANALYSIS.md: Detailed analysis of 7 interconnected proposals from project leadership (dynamic validator sizing, sustainable spin model, agent provisioning, etc.). Maps each against existing framework coverage and identifies major gaps requiring new mechanisms (M012-M014).

Agent Implementation

  • agents/packages/agents/src/characters/: Two production-ready ElizaOS character definitions:
    • registry-reviewer.ts (AGENT-001): Layer 2 agent for credit class/batch validation with 24-72h override windows
    • governance-analyst.ts (AGENT-002): Layer 1 agent for proposal analysis and voting tracking (recommended first deployment)

Core Framework

  • agents/packages/core/src/:
    • types.ts: Governance layer enum, OODA workflow types, workflow execution tracking, inter-agent message envelope
    • ooda-executor.ts: Stateless OODA loop executor with injectable step handlers and escalation as first-class outcome
    • config.ts: Environment configuration loader with sensible defaults for local development

MCP Plugins

  • agents/packages/plugin-ledger-mcp/:

    • client.ts: HTTP client wrapping Regen Ledger MCP endpoints (proposals, validators, credit classes, marketplace)
    • actions/analyze-proposal.ts: Core action for governance analysis with impact assessment
    • providers/ledger-state.ts: Context provider injecting current chain state into agent messages
  • agents/packages/plugin-koi-mcp/:

    • client.ts: HTTP client for KOI knowledge graph (semantic search, entity resolution, SPARQL, code graph)
    • providers/knowledge-context.ts: Context provider grounding agent analysis in institutional knowledge

Testing

  • agents/__tests__/: Comprehensive test suite:
    • ooda-executor.test.ts: Workflow execution, escalation thresholds, error handling
    • analyze-proposal.test.ts: Proposal analysis with real Regen Ledger response shapes
    • ledger-client.test.ts: MCP client HTTP behavior and authorization
    • koi-client.test.ts: Knowledge graph client endpoint routing

Infrastructure

  • agents/docker-compose.yml: PostgreSQL (pgvector) + Redis for agent state and memory
  • agents/init.sql: Database schema for agents, memories, workflow executions, governance events
  • agents/package.json: Monorepo configuration with workspace dependencies
  • agents/.env.example: Configuration template for local development
  • agents/tsconfig.json, agents/vitest.config.ts: TypeScript and test configuration

Notable Implementation Details

  1. Governance Layer Mapping: All agents explicitly declare their governance layer (Layer 1-4) in character definitions and workflow specs. Layer 2 agents include override window tracking.

  2. OODA as First-Class Pattern: The executor treats Observe-Orient-Decide-Act as a composable workflow primitive with injectable handlers, making it testable without external dependencies.

  3. Escalation as Outcome: Confidence thresholds (0

https://claude.ai/code/session_01VaznLWdK9Uxf3b4NvSK7E6

claude and others added 5 commits February 12, 2026 01:01
Comprehensive assessment covering governance architecture, agent orchestration,
tokenomics mechanisms, security model, and generalizability. Rates overall
feasibility as moderate-to-high with caveats around the specification-reality
gap, ElizaOS dependency, inter-agent coordination, and LLM reliability.

https://claude.ai/code/session_01HApBbQuEP529cmiPijDsaU
…pin model

Analyzes 7 interconnected proposals from project lead voice memo against the
existing framework. Maps gaps (dynamic validator sizing, sustainable revenue
model, agent-operator co-creator role, swarm coordination). Proposes 3 new
mechanisms (M012-M014), 3 governance processes (GOV-006-008), defines 13
measurable outcomes for agentic development, and provides a phased
incorporation path. Flags revenue insufficiency as critical blocker.

https://claude.ai/code/session_01HApBbQuEP529cmiPijDsaU
…k-sZ7EX

Add feasibility review of agentic tokenomics as agent swarm framework
Closes the #1 gap identified in FEASIBILITY-REVIEW.md: this repo had
~9,600 lines of specification and zero working code. This adds a
runnable ElizaOS-compatible agent scaffold.

What's included:
- packages/core: Inter-agent message envelope schema (addresses §2.3
  coordination gap), OODA workflow executor, shared types, config loader
- packages/plugin-ledger-mcp: Regen Ledger MCP client with governance
  proposal analysis action and ledger state provider
- packages/plugin-koi-mcp: KOI knowledge graph MCP client with
  semantic search and knowledge context provider
- packages/agents: AGENT-002 (Governance Analyst) and AGENT-001
  (Registry Reviewer) character files, CLI entrypoint
- 27 passing tests covering OODA executor, proposal analysis,
  and both MCP clients
- Docker Compose for local dev (PostgreSQL + pgvector, Redis)
- Database schema from phase-2/2.5 spec (agents, memories,
  workflow executions, decisions, inter-agent messages)

Built against ElizaOS v1.6.3 stable API.

https://claude.ai/code/session_01VaznLWdK9Uxf3b4NvSK7E6
@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @glandua, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request establishes the foundational code scaffold for the Regen Agentic Tokenomics framework, transitioning from detailed specifications to runnable implementations. It introduces core components for orchestrating AI agent swarms, including two reference agent characters, a robust OODA loop executor, and client libraries for interacting with the Regen Ledger and KOI knowledge graph. The changes also include a comprehensive test suite and a local development environment, alongside critical documentation that assesses the framework's feasibility and analyzes new strategic proposals. The overall aim is to bridge the gap between theoretical design and practical application, enabling phased deployment of autonomous agents within the Regen ecosystem.

Highlights

  • Documentation: Added comprehensive feasibility review and voice memo analysis documents, assessing the framework's viability and mapping new proposals.
  • Agent Implementations: Introduced two ElizaOS character definitions: 'Registry Reviewer' (Layer 2) and 'Governance Analyst' (Layer 1), with the latter recommended for initial deployment.
  • Core Framework: Implemented the 'OODA loop executor' for workflow orchestration, along with core types and an environment configuration loader.
  • MCP Client Libraries: Developed client libraries for 'Regen Ledger' and 'KOI knowledge graph' access, including specific actions like 'analyze-proposal' and context providers.
  • Test Suite: Established a comprehensive test suite covering workflow execution, proposal analysis, and client behavior for both Ledger and KOI MCPs.
  • Local Development Environment: Provided infrastructure setup including 'Docker Compose' for PostgreSQL (with pgvector) and Redis, a database schema, and monorepo configuration.
Changelog
  • FEASIBILITY-REVIEW.md
    • Added a comprehensive feasibility review of the agentic tokenomics framework.
  • VOICE-MEMO-ANALYSIS.md
    • Added a detailed analysis of interconnected proposals from project leadership.
  • agents/.env.example
    • Added an example environment configuration file for local development.
  • agents/.gitignore
    • Added a gitignore file for the agents directory.
  • agents/tests/analyze-proposal.test.ts
    • Added unit tests for the proposal analysis action.
  • agents/tests/koi-client.test.ts
    • Added unit tests for the KOI MCP client.
  • agents/tests/ledger-client.test.ts
    • Added unit tests for the Ledger MCP client.
  • agents/tests/ooda-executor.test.ts
    • Added unit tests for the OODA loop executor.
  • agents/docker-compose.yml
    • Added a Docker Compose configuration for local development services.
  • agents/init.sql
    • Added the initial PostgreSQL database schema with pgvector extension.
  • agents/package.json
    • Added the root package.json for the monorepo, defining scripts and dependencies.
  • agents/packages/agents/package.json
    • Added the package.json for the agents application.
  • agents/packages/agents/src/characters/governance-analyst.ts
    • Added the character definition for the Governance Analyst agent.
  • agents/packages/agents/src/characters/registry-reviewer.ts
    • Added the character definition for the Registry Reviewer agent.
  • agents/packages/agents/src/index.ts
    • Added the main entrypoint for the agent runtime.
  • agents/packages/core/package.json
    • Added the package.json for the core utilities.
  • agents/packages/core/src/config.ts
    • Added the environment configuration loader.
  • agents/packages/core/src/index.ts
    • Added the index file for the core package exports.
  • agents/packages/core/src/ooda-executor.ts
    • Added the OODA loop workflow executor implementation.
  • agents/packages/core/src/types.ts
    • Added core types for governance layers, OODA workflows, and inter-agent messages.
  • agents/packages/plugin-koi-mcp/package.json
    • Added the package.json for the KOI MCP plugin.
  • agents/packages/plugin-koi-mcp/src/client.ts
    • Added the KOI MCP client for knowledge graph access.
  • agents/packages/plugin-koi-mcp/src/index.ts
    • Added the index file for the KOI MCP plugin exports.
  • agents/packages/plugin-koi-mcp/src/providers/knowledge-context.ts
    • Added the knowledge context provider for KOI.
  • agents/packages/plugin-ledger-mcp/package.json
    • Added the package.json for the Ledger MCP plugin.
  • agents/packages/plugin-ledger-mcp/src/actions/analyze-proposal.ts
    • Added the action for analyzing governance proposals.
  • agents/packages/plugin-ledger-mcp/src/client.ts
    • Added the Ledger MCP client for on-chain data access.
  • agents/packages/plugin-ledger-mcp/src/index.ts
    • Added the index file for the Ledger MCP plugin exports.
  • agents/packages/plugin-ledger-mcp/src/providers/ledger-state.ts
    • Added the Ledger state provider.
  • agents/tsconfig.json
    • Added the TypeScript configuration for the monorepo.
  • agents/vitest.config.ts
    • Added the Vitest configuration for testing.
Activity
  • Initial commit by glandua, setting up the agent implementation scaffold and feasibility review documents.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@glandua
Copy link
Contributor Author

glandua commented Feb 13, 2026

How can we leverage the data module, to anchor agent actions to make them trackable and verifiable? This, combined with the ideas around chain native agent resourcing could make Regen Ledger a first class home for r/acc agents.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a comprehensive scaffold for the Regen Agentic Tokenomics framework, including core OODA loop execution logic, MCP client libraries for ledger and knowledge graph access, and reference agent character definitions. The implementation is well-structured and follows the OODA (Observe-Orient-Decide-Act) pattern as specified in the documentation. The inclusion of a test suite and local development environment (Docker Compose) significantly lowers the barrier for further development. My feedback focuses on improving the robustness of the OODA executor's condition parsing and enhancing type safety in the ledger plugin.

Comment on lines +127 to +135
/^(\w+)\s*(==|!=|>=|<=|>|<)\s*(.+)$/
);
if (!match) return true;

const [, field, op, rawValue] = match;
const actual = (decision as Record<string, unknown>)[field];
const expected = isNaN(Number(rawValue))
? rawValue.trim()
: Number(rawValue);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The current condition parser is quite rigid and may fail for common data types like booleans or strings containing numbers. For example, if a field is boolean true, comparing it against the string "true" will return false. Additionally, it doesn't handle quoted strings or dot notation for nested fields. Consider using a more robust expression evaluation strategy or at least adding support for boolean literals and basic quote stripping.

if (!match) return true;

const [, field, op, rawValue] = match;
const actual = (decision as Record<string, unknown>)[field];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Direct property access using an arbitrary string from the workflow definition can be risky. While workflow definitions are likely trusted, it is safer to verify that the property exists on the object and is not an inherited property (like toString or __proto__).

Suggested change
const actual = (decision as Record<string, unknown>)[field];
const actual = Object.prototype.hasOwnProperty.call(decision, field) ? (decision as Record<string, unknown>)[field] : undefined;

client: LedgerMCPClient,
proposalId: number
): Promise<ProposalAnalysis | null> {
const proposal = (await client.getProposal(proposalId)) as any;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Using as any here bypasses TypeScript's type checking. Since the MCP client returns structured data, defining an interface for the Ledger Proposal response would improve maintainability and catch potential breaking changes in the MCP API early.

Comment on lines +35 to +36
CREATE INDEX idx_memories_embedding ON agent_memories
USING ivfflat (embedding vector_cosine_ops);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The ivfflat index type in pgvector requires the index to be built after a significant amount of data is present to be effective, or it needs a pre-defined number of lists. For general-purpose semantic search in agent memory, the hnsw index type is often preferred as it provides better performance and doesn't require rebuilding as the dataset grows.

CREATE INDEX idx_memories_embedding ON agent_memories
    USING hnsw (embedding vector_cosine_ops);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants