miyabi-a2a
Agent-to-Agent (A2A) task storage and communication for Miyabi.
Overview
miyabi-a2a provides task storage and coordination infrastructure for multi-agent collaboration in the Miyabi framework. Tasks are persisted as GitHub Issues, providing natural visualization and workflow integration.
Features
- GitHub Issues Backend: Uses GitHub Issues as persistent storage (no additional infrastructure required)
- Type-Safe API: Strongly typed task representation with async/await support
- Status Management: Automatic label-based status tracking
- Filtering: Query tasks by status, context, agent, and timestamp
- Natural UI: View and manage tasks directly in GitHub's issue tracker
Installation
Add to your Cargo.toml:
[]
= { = "0.1.0", = "../miyabi-a2a" }
Quick Start
use ;
use Utc;
async
API Reference
Core Types
A2ATask
Represents a task that can be exchanged between agents.
TaskStatus
Task lifecycle states:
Pending: Task created, awaiting processingInProgress: Task currently being worked onCompleted: Task successfully completedFailed: Task failed with errorsBlocked: Task blocked by dependencies
TaskType
Task classification:
CodeGeneration: Code generation taskCodeReview: Code review taskTesting: Testing taskDeployment: Deployment taskDocumentation: Documentation taskAnalysis: Analysis task
Storage Operations
save_task(task: A2ATask) -> Result<u64>
Create a new task. Returns the assigned task ID (GitHub Issue number).
let task_id = storage.save_task.await?;
get_task(id: u64) -> Result<Option<A2ATask>>
Retrieve a task by ID. Returns None if not found.
if let Some = storage.get_task.await?
list_tasks(filter: TaskFilter) -> Result<Vec<A2ATask>>
List tasks with optional filters.
use TaskFilter;
let filter = TaskFilter ;
let tasks = storage.list_tasks.await?;
list_tasks_paginated(filter: TaskFilter) -> Result<PaginatedResult<A2ATask>>
List tasks with cursor-based pagination for efficient navigation through large task lists.
Pagination Features:
- ✅ Stable cursors (Base64-encoded)
- ✅ Forward/backward navigation
- ✅ Configurable page size (default: 50, max: 100)
- ✅
has_moreflag for detecting last page - ✅ Compatible with all filters
use TaskFilter;
// First page (50 items by default)
let filter = TaskFilter ;
let page1 = storage.list_tasks_paginated.await?;
println!;
// Navigate to next page
if let Some = page1.next_cursor
Cursor Format: Opaque Base64-encoded JSON containing {last_id, last_updated, direction}. Cursors are stable across requests.
Performance: Same as list_tasks() - uses API-level filtering for status, in-memory for other criteria.
update_task(id: u64, update: TaskUpdate) -> Result<()>
Update an existing task.
use TaskUpdate;
let update = TaskUpdate ;
storage.update_task.await?;
delete_task(id: u64) -> Result<()>
Delete a task (closes GitHub Issue).
storage.delete_task.await?;
GitHub Integration
Label Mapping
Tasks use GitHub labels for status and type tracking:
Status Labels:
a2a:pendinga2a:in-progressa2a:completeda2a:faileda2a:blocked
Type Labels:
a2a:codegena2a:reviewa2a:testinga2a:deploymenta2a:documentationa2a:analysis
Required Permissions
The GitHub token requires the following scopes:
repo(full repository access)
Set via environment variable:
Testing
# Run unit tests
# Run with GitHub integration (requires GITHUB_TOKEN)
GITHUB_TOKEN=ghp_xxx
Performance & Optimization
Current Implementation
Hybrid Filtering: API-level + In-memory filtering for optimal performance.
// Status filtering: API-level (GitHub labels)
let filter = TaskFilter ;
let tasks = storage.list_tasks.await?;
Performance Characteristics
API-level Filtering (✅ Implemented)
Status Filtering: Uses GitHub API label queries
// GitHub API request
GET /repos/:owner/:repo/issues?labels=a2a:pending&per_page=30
Performance:
- Network Transfer: 90% reduction for status queries
- Query Time: <50ms (GitHub servers)
- Example: 10 pending tasks → 10 Issues fetched (vs 100 with in-memory)
In-memory Filtering
Other Filters: context_id, agent, last_updated_after
- Applied after API fetch
- Performance: <1ms (local filtering)
- Reason: Not supported by GitHub Issues API labels
Optimization Results
Before (MVP):
100 Issues fetch → 100 transfers → In-memory filter → 10 matches
Network: 100 Issues | Time: ~200ms
After (Optimized):
Label filter → 10 Issues fetch → 10 transfers → In-memory filter → 10 matches
Network: 10 Issues | Time: ~50ms
Improvement:
- ✅ 90% less network traffic
- ✅ 75% faster query time
- ✅ Scales better with large task counts
Roadmap
Cursor-based Pagination (Issue #279):
- ✅ Paginate through large result sets
- ✅ Support for 1000+ tasks
- ✅ Forward/backward navigation with stable cursors
GraphQL API (Future):
- ⏳ Full API-level filtering (context_id, agent, timestamps)
- ⏳ Single-request multi-field queries
Examples
See the examples directory for complete usage examples:
- Basic CRUD operations
- Multi-agent coordination
- Status transitions
Architecture
┌─────────────────────────────────────────┐
│ TaskStorage Trait │
│ (Abstract storage interface) │
└────────────────┬────────────────────────┘
│
│ implements
▼
┌─────────────────────────────────────────┐
│ GitHubTaskStorage │
│ (GitHub Issues backend) │
└────────────────┬────────────────────────┘
│
│ uses
▼
┌─────────────────────────────────────────┐
│ octocrab │
│ (GitHub API client) │
└─────────────────────────────────────────┘
Roadmap
- Pagination support (cursor-based)
- Webhook integration for real-time updates
- Cache layer for improved performance
- Context ID extraction from Issue body
- Priority extraction from labels
- Alternative storage backends (PostgreSQL, SQLite)
License
Apache-2.0
Related
- Issue #281 - task storage backend
- Milestone 26 - Phase 2: Streaming & Push Notifications