HAI sprint dev — AI Dev Team

Title: Integrate OpenClaw, Hermes and Odysseus Into HAI — AI Dev Team Budget: $200 fixed price Engagement: One-off implementation sprint, one final delivery, no paid milestones I am looking for a small, highly capable, AI-native software development team to repair, complete, wire together, and substantially enhance HAI: my local-first, governed Personal AI Operating System. The assignment must begin by fully analysing OpenClaw, Hermes Agent, and Odysseus and incorporating all relevant, legally compatible features from those projects into HAI. This is not a request to build one autonomous-agent loop, create a superficial demonstration, or copy a few convenient components. The objective is broad capability coverage across HAI and all its intended agents. I want the team to deliver the maximum possible amount of working, integrated, tested progress within a fixed one-off budget of $200. AI-assisted development is encouraged The team may use: * Codex * ChatGPT * Claude * Gemini * Cursor * GitHub Copilot * Parallel coding agents * Automated repository-analysis tools * AI-generated tests and documentation * Other appropriate AI development systems I care about the resulting functionality and quality, not whether every line was written manually. However, AI-generated code must be understood, integrated, executed, reviewed, and tested. Large quantities of disconnected generated code will not count as progress. One technical lead must remain accountable for: * Architecture * Task distribution * Interface contracts * Repository coordination * Code review * Integration * Security * Testing * Documentation * The final working delivery What HAI is HAI is not simply a chatbot, agent framework, workflow builder, or collection of autonomous scripts. HAI is intended to become a coherent, local-first, governed Personal AI Operating System for coordinating my personal life and businesses. Its purpose is to quietly coordinate: * Goals and long-term pursuits * Obligations and responsibilities * Projects and cases * Information and evidence * Decisions * Plans and workflows * Specialist AI agents * Human virtual assistants * Tools and connected services * Authorized real-world actions * Verification and follow-up * Longitudinal learning HAI should normally show me: * Outcomes * Meaningful progress * Exceptions * Blockers * Risks * Decisions requiring my attention * Actions requiring approval It should not overwhelm me with every backend process. Nevertheless, I must always be able to: * Ask why * Inspect evidence * Inspect the complete logic * Correct HAI * Constrain an agent * Pause a pursuit * Revoke authority * Take over work * Cancel an operation * Activate a global emergency stop The global execution path The canonical HAI path is: 1. Authenticated dashboard 2. Source ingestion and memory 3. Goal and state interpretation 4. World model 5. Planning 6. Model, agent, skill, and tool routing 7. Policy and approval gates 8. Controlled execution 9. Observation and independent verification 10. Workflow and pursuit state 11. Audit, memory, evaluation, and lessons Planning, approval, execution, verification, and completion must remain separate. A model saying that something succeeded is not verification. The Operation or Workflow Ledger must be the restart-safe authority for what is happening. PostgreSQL must remain the canonical source of truth. Search indexes, vector databases, external agents, and specialist memories may project or retrieve information, but they must not silently become competing sources of truth. Existing technical direction The existing HAI architecture includes or is intended to include: * Angular dashboard * Go APIs * Identity provider * API gateway * PostgreSQL * Redis * Kafka * Docker Compose * LLM routing * Memory * Connected-source ingestion * Workflow management * Guarded runtime adapters * Approval controls * Verification * Evidence * Audit logging The development team must inspect the actual repository rather than assuming every listed component is complete or working. HAI currently has CI coverage involving the backend, frontend, identity provider, Nginx configuration manager, and local Compose validation. Recent history indicates that backend builds or tests may still be failing while other jobs succeed. Repairing the actual build and runtime is therefore a priority. The role of OpenClaw, Hermes Agent, and Odysseus OpenClaw, Hermes Agent, and Odysseus are required runtime integrations. They must not replace HAI, become alternative governance systems, or create separate uncontrolled autonomy planes. HAI remains responsible for: * Goals * Pursuits * Policies * Authority * Permissions * Planning * Assignment * Approvals * Canonical state * Evidence * Verification * Audit * User control OpenClaw, Hermes Agent, and Odysseus should operate as bounded specialist runtimes, executors, or capability providers underneath HAI’s authority. They must interact with HAI through mechanisms such as: * HAI-native capability cards * Typed task contracts * Typed artifact contracts * Operation Ledger records * Permission boundaries * Approval requirements * Evidence packs * Verification contracts * Audit records * Runtime health checks * Self-tests * Truthful availability reporting Complete feature-coverage requirement I want all relevant features from OpenClaw, Hermes Agent, and Odysseus considered for inclusion. This does not mean blindly merging every source file. It means complete feature accounting followed by the integration, adaptation, or HAI-native reproduction of every useful and compatible capability. The team must create a feature-parity inventory covering the three upstream projects and HAI. For every discovered feature, record: * Project and version or commit * Feature name * Purpose * User-facing or internal behaviour * Dependencies * Licence * Security implications * Equivalent HAI capability, if one exists * Integration approach * Implementation status * Test status * Documentation status * Reason for any exclusion Every feature must receive one of these dispositions: * Integrated directly * Adapted for HAI * Reimplemented through an HAI-native interface * Already present in HAI and retained * Consolidated with an existing HAI feature * Constrained because the upstream implementation is unsafe * Excluded because it is irrelevant * Excluded because of incompatible licensing * Deferred because it could not be completed within the sprint * Blocked by missing credentials, hardware, services, or external access “Deferred” must not be used to hide features that were never examined. Deferred items must remain in a prioritized backlog with their requirements and recommended implementation path. Complete capability analysis The feature-parity analysis must cover at least: * Agent runtimes * Agent definitions * Goal handling * Planning * Replanning * Reasoning patterns * Tool use * MCP * Skills * Plugins * Extensions * Memory * Context management * Knowledge retrieval * Multi-agent orchestration * Delegation * Parallel execution * Background tasks * Scheduling * Events and triggers * Browser interaction * Computer interaction * Coding capabilities * Shell and script execution * File operations * Communication integrations * Model providers * Model routing * Local models * Cost management * Permissions * Approval systems * Sandboxing * Credential handling * Recovery * Retry behaviour * Checkpointing * Observability * Logs * Metrics * User interfaces * Configuration * Installation * Deployment * Updates * Testing * Documentation All HAI agents must participate This assignment is not complete when one agent can execute one demonstration loop. The team must inventory all existing HAI agents, agent definitions, prompts, workflows, and related modules. For every HAI agent, identify: * Name * Purpose * Domain * Trigger conditions * Supported goals * Required inputs * Expected outputs * Tools * Skills * MCP capabilities * Memory access * Model requirements * Permissions * Approval rules * Dependencies * Failure behaviour * Current implementation status * Integration status * Test coverage * Remaining limitations Every existing agent must be classified as: * Working and connected * Repaired and connected * Partially working with documented limitations * Duplicated and consolidated * Intentionally disabled with an explanation * Obsolete and recommended for removal * Not yet implemented All viable agents should be connected to the shared HAI runtime. There must not be a collection of agents that each invents its own incompatible planning, memory, status, tool, approval, or completion system. Shared agent lifecycle Every applicable agent should operate through a consistent lifecycle: 1. Receive or discover a goal or trigger. 2. Identify the applicable pursuit and owner. 3. Establish relevant state. 4. Retrieve relevant memory and evidence. 5. Apply policy and authority constraints. 6. Decompose the work. 7. Identify dependencies, risks, and blockers. 8. Create or update a plan. 9. Select the appropriate model, agent, tool, skill, or runtime. 10. Determine whether approval is required. 11. Execute an authorized action. 12. Observe the result. 13. Verify the result independently. 14. Record progress and evidence. 15. Retry, replan, delegate, pause, or escalate when necessary. 16. Continue until completed, blocked, cancelled, or waiting. 17. Produce a source-supported completion report. 18. Store confirmed outcomes and useful lessons. HAI must distinguish between states such as: * Candidate * Proposed * Planned * Ready * Awaiting approval * Running * Verifying * Waiting for dependency * Waiting for external response * Interrupted * Paused * Blocked * Partially completed * Completed * Failed * Dismissed * Cancelled * Superseded * Archived Interrupted operations require review. Stale approvals must be invalidated when relevant source information or proposed actions change. Completion requires verification unless verification is explicitly marked unnecessary with a recorded reason. Pursuits and goals A pursuit is HAI’s durable representation of a goal, responsibility, opportunity, project, problem, or case. HAI should support: * Candidate pursuits * Approved pursuits * Goals and subgoals * Success criteria * Evidence requirements * Priority * Deadlines * Dependencies * Constraints * Stakeholders * Resources * Risks * Milestones * Progress * Blockers * Alternative strategies * Goal conflicts * Pausing * Resumption * Abandonment * Supersession * Completion * Periodic review Candidate pursuits must remain non-executable until approved. Goals should be connected to real outcomes, not merely task completion or generated text. Planning and cognition HAI should have an architecture-aware meta-controller capable of selecting an appropriate planning mode. Relevant approaches include: * Deterministic workflows * ReAct for relatively linear tool-based tasks * Tree-of-Thought or LATS-style exploration for branching problems * DAG orchestration for decomposable work * Rule-based routing * Human or virtual-assistant delegation * Hybrid automated and manual workflows The system should support: * Goal decomposition * Plan creation * Dynamic replanning * Precondition checks * Dependency-aware execution * Sequential execution * Parallel execution * Stop conditions * Retry conditions * Escalation conditions * Resource budgets * Context budgets * Alternative strategies * Post-action evaluation The team must not put every available framework into every task. Each framework must have an explicit jurisdiction and be selected only where appropriate. Multi-agent collaboration HAI should enable: * Specialist-agent discovery * Capability-based routing * Structured delegation * Subtask assignment * Shared project context * Typed handoffs * Evidence exchange * Result review * Supervisor agents * Peer review * Parallel work * Dependency coordination * Conflict detection * Output consolidation * Workload awareness * Duplicate-work prevention * Agent cancellation * Agent replacement * Agent recovery Agents should exchange structured tasks, artifacts, evidence, status, and constraints—not only conversational text. Unified capability layer HAI should have one coherent capability layer covering: * Internal tools * MCP servers * Skills * Plugins * APIs * Browser automation * Computer interaction * Local scripts * Coding systems * Repository tools * Communication services * Calendar services * File systems * Data sources * Human virtual assistants * Future robots and physical automation Each capability should describe: * Identifier * Purpose * Input schema * Output schema * Authentication state * Availability * Runtime location * Required authority * Risk level * Expected cost * Context cost * Timeout * Retry behaviour * Reversibility * Approval requirements * Verification method * Evidence returned OpenClaw, Hermes, and Odysseus capabilities must be projected into this HAI-native capability layer rather than exposed as uncontrolled alternatives. Memory and evidence HAI should support distinct forms of memory, including: * Raw source memory * Episodic memory * Semantic memory * Procedural memory * Decision memory * Project memory * Relationship memory * Preference memory * Agent-run memory * Failure memory * Outcome memory The memory system should support: * Provenance * Original timestamps * Confidence * Verification state * Source revisions * Contradictions * Superseded information * Sensitivity * Retention * Access control * Relevance * Retrieval limits * Progressive retrieval * Duplicate detection HAI must distinguish between: * Original evidence * User-confirmed facts * Deterministic observations * Agent-generated summaries * Inferences * Assumptions * Unverified claims Every meaningful conclusion should remain traceable to its evidence. HAI must also be ready to connect to a separate MCP-based unified memory system for personal ChatGPT, ChatGPT Work, and Codex installations on two local computers. Context management Each agent should receive the smallest reliable context package necessary for its work. Context management should support: * Token budgets * Context prioritization * Project isolation * Owner isolation * Progressive retrieval * On-demand detail * Source-linked summaries * Previous-attempt retrieval * Applicable policies * User preferences * Task constraints * Current plan * Recent tool results * Relevant evidence * Detection of outdated context HAI must not send all stored information to every model or agent. Proactive and background autonomy HAI’s autonomy modes include: * `paused` * `read_only` * `draft_only` * `approval_required` * `autonomous_safe` * `emergency_stopped` HAI should support: * Persistent task queues * Background workers * Run-once autonomy cycles * Scheduled tasks * Recurring tasks * Event-driven work * Conditional triggers * Account-feed inspection * Monitoring * Waiting for external conditions * Timeouts * Wake-up and continuation * Resumable runs * Concurrency controls * Rate-limit handling * Stuck-task detection * Continuity after restart It should distinguish between: * No new information * An offline source * Missing credentials * An unavailable runtime * A blocked task * A failed action * An inconclusive verification Unavailable adapters must fail closed and report their actual state. Permissions, approvals, and safety Autonomy must be calibrated per action, not enabled through one unrestricted global setting. Agents cannot: * Expand their own authority * Change constitutional rules * Disable safety boundaries * Approve their own high-risk actions * Treat missing approval as approval * Claim external success without evidence HAI should classify actions such as: * Read-only * Reversible local change * Draft creation * External communication * Calendar change * Financial action * Legal or governmental submission * Publication * Account or permission change * Sensitive-data access * Destructive action * Physical or robotic action Depending on the action, HAI should support: * Autonomous execution * Draft-only behaviour * One-time approval * Approval for every action * Approval within a defined risk or spending boundary * Mandatory preview * Complete prohibition An approval request should show: * Proposed action * Reason * Requesting agent * Supporting evidence * Information that will be shared * Expected consequences * Reversibility * Expected cost * Risk * Recommendation * Consequence of inaction Every autonomy decision should record: * Reason * Evidence * Applicable policy * Risk * Autonomy level * Owner * Review time * Approval requirement * Result of my Yes or No decision Security requirements include: * Least-privilege access * Credential isolation * Secret-safe logging * Permission-aware retrieval * Prompt-injection resistance * Tool-input validation * Output validation * Allowlisted execution * Sandboxing * Timeouts * Bounded retries * Rate limits * Audit trails * Emergency stopping at execution boundaries * Protection against unauthorized MCP access * Local and private processing where practical No credentials, tokens, private histories, or personal data may be committed to GitHub. Model and resource routing HAI should support multiple local and remote model providers. The existing direction includes possible use of: * Hosted LLM providers * Local Windows hardware * DSpark * Ollama * LM Studio * Architecture-aware model profiles * Privacy-filtered local processing * Different routing lanes Routing may consider: * Task complexity * Reliability requirements * Context length * Tool requirements * Privacy * Speed * Model availability * Cost * Token budget * Previous performance * Required output format The routing system must be understandable and inspectable. Missing models or providers must be reported truthfully rather than simulated. Verification and truthful completion HAI must verify work before marking it completed. Depending on the action, verification may include: * Automated tests * Schema validation * Build validation * Type checking * File inspection * Content comparison * Database confirmation * API confirmation * Browser inspection * Screenshots * Source confirmation * Independent-agent review * Acceptance-criteria evaluation * User confirmation The system should produce evidence packs containing: * Intended action * Actual action * Result * Verification method * Evidence * Remaining uncertainty * Relevant timestamps * Responsible agent or runtime Dashboard and progressive disclosure The HAI Command Dashboard should be an exception-driven executive cockpit—not an administrator console or raw agent-trace viewer. Level 1 should show: * Outcomes * Exceptions * Status * Next steps * Items requiring attention * Interruption controls Level 2, the pursuit workspace, should show: * Goals * Milestones * Plans * Activity * Agent and human roles * Decisions * Evidence * Deadlines * Resources * Controls Level 3 should show: * Rationale * Assumptions * Alternatives * Evidence * Authority * Recommended action * Consequences Level 4 should expose: * Technical traces * Tool calls * Model calls * Internal state * Logs * Debugging information Level 4 must remain available but must not be the default experience. “Needs your attention” should include: * Approvals * Clarification * Conflicting evidence * High-risk actions * Missing permissions * Budget or deadline risk * Failures * Inconclusive verification * External responses * Recommendations to change, pause, or abandon a pursuit Every attention item should explain: * What is needed * Why * Urgency * Consequence of inaction * HAI’s recommendation * Available controls * A clear “Why?” option Dashboard state is visibility, not proof that an external action occurred. Connected domains HAI is intended to work across personal and business domains, including: * Gmail * Google Drive * Google Calendar * GitHub * Trello * Local files * Chat imports * Browser-based information * Upwork * Projects and businesses * Administrative and governmental cases * Legal matters * Personal obligations * Travel * Mobility * Emergency and continuity planning * Human virtual assistants * Future smart-home and robotic systems Official APIs and controlled adapters are preferred. Where automation is unsafe or unavailable, HAI must support assisted or manual workflows rather than pretending the integration works. Parallel development team I prefer a small software development team that can work in parallel while maintaining one coherent architecture. Possible workstreams include: * Technical leadership and architecture * HAI repair and CI * OpenClaw analysis and integration * Hermes Agent analysis and integration * Odysseus analysis and integration * Agent runtime and orchestration * Memory and context * Tools, MCP, skills, and plugins * Safety and approvals * Backend and infrastructure * Dashboard and observability * Testing and documentation The team must use disciplined coordination, including: * Defined interface contracts * Separate branches or worktrees * Clear file ownership * Small, reviewable commits * Frequent integration * Automated formatting * Linting * Type checking * Unit tests * Integration tests * Continuous integration * Review by someone or an AI agent other than the original author * Final regression testing I do not want several developers or coding agents independently changing the same architecture and leaving unresolved conflicts. Priority order Within the fixed budget, prioritize: 1. Make HAI build, install, and start reliably. 2. Repair failing backend tests and core runtime errors. 3. Inventory every HAI agent and subsystem. 4. Inventory every feature from OpenClaw, Hermes, and Odysseus. 5. Stabilize the canonical data and Operation Ledger. 6. Establish the shared autonomy runtime. 7. Connect all viable HAI agents. 8. Integrate upstream capabilities through HAI-native boundaries. 9. Establish persistent tasks, checkpoints, and recovery. 10. Connect memory, planning, tools, MCP, approvals, and verification. 11. Enable multi-agent delegation and parallel execution. 12. Strengthen safety, audit, and truthful readiness reporting. 13. Improve the exception-driven dashboard. 14. Test end-to-end multi-agent pursuits. 15. Document everything that remains incomplete. Breadth is important, but the repository must remain coherent and executable. Quality requirements The final repository must not contain: * Fake integrations * False completion claims * Disconnected generated modules * Invented APIs * Calls to nonexistent functions * Placeholder success responses * Fake tests * Tests that are never executed * Suppressed errors * Hard-coded credentials * Unexplained duplicate implementations * Unnecessary dependencies * Dead code presented as working * Documentation that contradicts the application * Unrestricted desktop or browser-control claims * Features marked operational without health checks or evidence Each capability should have a truthful claim level, such as: * Declared * Configured * Available * Health-checked * Self-tested * Integration-tested * Demonstrated * Production-ready The system must not confuse “code exists” with “capability works.” Required deliverables The one-off delivery must include: * Updated HAI source code * Repaired build and runtime * Repaired CI where feasible * Complete HAI-agent inventory * Complete OpenClaw feature inventory * Complete Hermes Agent feature inventory * Complete Odysseus feature inventory * Feature-parity and disposition matrix * Licence and attribution record * Integrated compatible upstream components * Shared HAI autonomy runtime * Connected viable HAI agents * HAI-native capability layer * Persistent Operation Ledger * Memory and context integration * Planning and routing integration * Permission and approval controls * Verification and evidence handling * Multi-agent delegation * Background or resumable execution * Health checks and runtime self-tests * Truthful capability-readiness reporting * Useful logs and observability * Improved dashboard integration where feasible * Installation and configuration fixes * Environment-variable example without secrets * Automated tests * Continuous-integration configuration * End-to-end multi-agent demonstrations * Architecture documentation * Installation instructions * Operating instructions * Security notes * List of repaired defects * List of implemented capabilities * List of partially implemented capabilities * List of excluded capabilities and reasons * Prioritized backlog of deferred features * All work committed and pushed to my designated GitHub repository * Final handover report End-to-end demonstration The final demonstration must involve multiple HAI agents and should show HAI: 1. Receiving or discovering a meaningful pursuit. 2. Retrieving relevant sources and memory. 3. Interpreting goals and constraints. 4. Creating a plan. 5. Assigning work to several appropriate agents. 6. Using capabilities originating from OpenClaw, Hermes, or Odysseus. 7. Executing sequential and parallel work. 8. Sharing structured artifacts between agents. 9. Detecting a failure, conflict, or blocker. 10. Replanning or escalating appropriately. 11. Requesting approval for a consequential action. 12. Respecting the approval decision. 13. Resuming after interruption. 14. Verifying completed actions. 15. Producing an evidence pack. 16. Updating the pursuit and Operation Ledger. 17. Presenting a concise outcome through the dashboard. 18. Preserving relevant memory for future continuation. A single-agent demonstration will not satisfy this requirement. Budget and engagement terms The complete fixed price is $200. This is one implementation sprint with one final delivery. I do not use paid milestones for this assignment. I understand that $200 does not purchase the manual construction of an entire production-ready Personal AI Operating System from scratch. That is why: * HAI already exists * OpenClaw already exists * Hermes Agent already exists * Odysseus already exists * Extensive AI-assisted development is permitted * Parallel coding agents are encouraged * Reuse is required before reinvention I expect the team to obtain the maximum leverage from the existing repositories and modern AI development tools. The complete breadth of the requested system must be analysed. The team must implement as much verified capability as possible and document the remainder honestly. Who should apply Suitable applicants include: * A small AI-native software development team * A senior technical lead with coordinated developers * A senior developer managing organized parallel coding agents * A team experienced with autonomous multi-agent systems * Developers experienced with Go, Angular, PostgreSQL, Redis, Kafka, and Docker * Developers familiar with MCP, skills, tools, memory, planning, and model routing * Developers who can rapidly understand unfamiliar repositories * Teams with disciplined Git, testing, review, and integration practices * Developers who reuse proven systems instead of automatically rewriting them A solo developer may apply only if they can demonstrate an organized AI-assisted parallel-development process and accept responsibility for the entire integration. The purpose of this assignment is to push HAI forward as broadly, rapidly, and intelligently as possible—while preserving one coherent architecture, truthful capability reporting, human control, and verifiable quality.