6 posts tagged with "AI MCP"

Ansina Just Got a Heart and a Brain​

Deliver three foundational systems that move Ansina from prototype toward a composable, enterprise-ready runtime: a formal Heart protocol, an autonomic tick loop, and a flexible, OpenAI-compatible Brain interface.

Heart: A Formal Runtime Protocol with MLX Support​

The new Heart runtime protocol (heart/runtime.py) formalizes how the agent signals intent and responds to runtime events, making behavior predictable and testable. A dedicated MLX adapter (heart/adapters/mlx.py) bridges the Heart to an external ML execution layer, and new heartbeat endpoints (api/routes/heart.py) give orchestration layers full visibility into runtime state, backed by comprehensive tests.

BrainProvider: Swap Models Without Touching Code​

The new BrainProvider abstraction (brain/provider.py) centralizes model invocation, retries, and selection logic. Paired with an OpenAI-compatible adapter (brain/adapters/openai_compat.py), Ansina now integrates with local models or any third-party provider speaking the OpenAI API standard — no code changes required. Configuration is fully exposed via settings and example files, so teams can switch providers as a configuration decision — a real step toward vendor flexibility and cost control at scale.

Autonomy: A Tick Loop That Keeps Agents Honest​

The new autonomic tick loop (heart/tick/loop.py) drives periodic decision cycles and lifecycle transitions automatically, keeping the agent running gracefully under partial failure. Decision logic, snapshots, and selection strategy are cleanly separated for easier auditing and replay. The loop integrates directly with Heart events and BrainProvider calls, making retries and pacing explicit and observable, with deterministic snapshots supporting reproducible debugging.

Developer Experience and Reliability​

This release also strengthens the foundation for teams building on Ansina: updated docs and architecture blueprints, a fuller dependency lockfile for build reproducibility, a tightened API and error surface for actionable telemetry, and extensive new unit tests across the codebase.

Why This Matters​

Ansina moves decisively toward a production-grade runtime: clear heartbeat contracts, a vendor-agnostic brain interface, and an autonomic loop that keeps agents moving even when components fail. This combination of reliability, interoperability, and configurability makes Ansina worth a closer look.

Onward — building agents with both heart and brain.

Laid the foundation: core infra, API, auth, persistence, CI, tests and docs — a production-minded M0 skeleton for Ansina.

Lead A focused engineering sweep to make Ansina reviewable and operable without any model code. The PR delivers a full infra baseline (packaging, config, logging already merged via #19), then adds REST endpoints, auth, persistence primitives, CI gates, testing conventions and docs scaffolding. All checks (unit + e2e, both OS legs) are green; branch is still a draft pending final author flip to "ready for review."

🚧 What this PR adds

• 🧩 REST: 🛣️ API skeleton and middleware (src/ansina/api/app.py, routes/health.py, middleware.py, exception_handlers.py) to standardize request/response flows.
• 🔐 Auth: 🪪 API authentication and public endpoints (src/ansina/api/auth.py) with tests to validate behavior.
• 💾 Persistence: 🧰 DB foundation, migrator and initial migration (src/ansina/storage/database.py, migrator.py, migrations/0001_init.sql).
• 📄 Docs & README: 📝 README rewrite and docs scaffolding (docs/architecture/blueprint.md) to explain architecture sections §3–§5.

⚙️ CI, tests, and quality gates

• 🧪 Tests: ✅ Unit + E2E tests added (tests/unit/*, tests/e2e/test_server.py) and a testing strategy that defines unit conventions + E2E build validation gate.
• 🔁 CI pipeline: 🛠️ .github/workflows/ci.yml implements unit and E2E jobs; both OS legs pass on CI.
• 🧹 Hygiene: ✨ pre-commit, Makefile, pyproject tweaks and .gitignore updates to keep developer UX smooth.

🧭 Engineering choices & tradeoffs

• ⚖️ Separation: Model code intentionally excluded — M0 focuses on stability, contracts, and reproducible ops before wiring inference.
• 🧪 Validation-first: E2E gate ensures the runnable artifact builds cleanly on multiple OS runners before merging downstream model work.
• 📚 Documented: Architecture blueprint and examples (ansina.example.toml) make onboarding and future design decisions explicit.

🔎 Files and signals worth scanning

• 🔁 CI + tests: .github/workflows/ci.yml, tests/e2e/test_server.py
• 🧭 API surface: src/ansina/api/app.py, auth.py, routes/health.py, readiness.py
• 🗄️ Storage: src/ansina/storage/database.py, migrator.py, migrations/0001_init.sql
• 📘 Docs: README.md, docs/architecture/blueprint.md

This was a foundation-first sprint: stable contracts, testable CI, and readable docs — readying Ansina for the next phase where model integration becomes a consumer of this platform.

Onward to M1 — wire the models once the infra is battle-tested.

Hook: We pivoted to a pragmatic architecture — single-agent A2A — while keeping the original tri-node design one uncomment away.

Lead: After end-to-end tests showed sub-agent → A2A is unreliable in OpenClaw, the team chose stability and observability over brittle enforcement. The result: main does cross-agent calls directly, tri-node is parked (preserved), MCP tooling added, and docs + tests updated.

🔁 Why we pivoted

• ⚠️ Sub-agent A2A break: tests showed a sub-agent cannot reliably drive another agent over A2A; the break is the sub-agent+cross-agent combination.
• 🔍 Practical trade: preserve the tri-node design, but avoid production fragility by routing A2A from main→main.
• ♻️ Preserve, not delete: tri-node config, prompts, and workspaces remain in-place as JSON5 comments and IDENTITY.tri-node.md (tag v0.1.0 = revival baseline).

🛠️ What changed (concrete)

• 🧭 Single-agent mode: both containers make main the working agent; when code is needed Researcher main curls Coder at http://coder:3000/a2a/tasks.
• 🗂️ JSON5 preservation: sub-agent entries commented in openclaw.json so revival is one uncomment away.
• 🧰 Local MCPs: added filesystem MCP for Coder and memory MCP for Researcher; tools surface as bundle-mcp:<server>__<tool>.
• 🧪 Orchestration + tests: index.js remained logic-identical (comments updated); tmux vm-bridge used for live runs and probes.

✅ What we validated

• 🔎 Spawn logs: live single-agent tasks showed spawn_count = 0 — no sub-agent spawn.
• ↔️ A2A round-trip: Researcher→Coder→Researcher worked in live tests (Coder logged payload, returned structured JSON, Researcher folded result.output).
• 🧰 MCP probe: openclaw mcp doctor files → files: ok; doctor memory → memory: ok; live tool calls returned expected results.
• ⚙️ Docs & artifacts: AGENTS.md + README updated, diffs and diffstat adjusted, IDENTITY.tri-node.md preserved, tag v0.1.0 recorded.

📌 Edge cases, constraints & next steps

• 🪪 Prompt hygiene: observed headless-output violations (narration prefixes, markdown fences) and a fallback self-write when Coder was down — these are prompt-enforcement issues to fix, not A2A plumbing failures.
• 🔁 Operational note: to pick up MCP config changes, restart the container (sudo podman restart) — do NOT use pm2 restart openclaw-gateway (it can orphan the gateway).
• 🛠️ Revival path: once OpenClaw fixes cross-agent delegation from sub-agents, simply uncomment JSON5 entries + swap IDENTITY.tri-node.md back to resume tri-node operation.
• 🚦 Next: tighten prompt enforcement, add CI smoke-tests for A2A round-trip, and monitor upstream OpenClaw fixes to evaluate revival.

Final: Practical pivots win — preserved the long-term design while shipping a robust, testable PoC for cross-agent work.

Architecting Real AI Production Systems 🛠️​

Here is what went from my keyboard to production this week:

🚀 OpenClaw on Kubernetes: Took our multi-agent routing infrastructure off a single VM and containerized it into K8s. Why? Because manual infrastructure management is a waste of engineering time. We need scale on-demand, and now we have "Agents as Code."

🤖 Overcoming Weak Models: We are running a modest open-source GLM 5.1 model to handle 24/7 autonomous build/ship tasks. Weak models struggle in headless environments. Instead of throwing expensive cloud compute tokens at it, I engineered custom Model Context Protocol (MCP) servers to give it the tools, context, and discovery paths it needs to act autonomously without hand-holding.

🔍 Shipped: The SEO MCP Server: I built and deployed a new MCP server designed specifically to monitor 4xx proxy errors across our sites, hook into APIs, and actively allow AI agents to fix broken user paths before it impacts our SEO. It’s running right now over the weekend, fixing human mistakes proactively. The

Takeaway: Stop waiting for a "smarter" model to solve your complex workflows. Build the tooling, structure the autonomy, and coordinate the system heartbeats so your agents can run without you. If your infrastructure isn't working while you sleep, you're doing it wrong.

Stop talking about AI "wrappers" Start talking about Multi-Agent Autonomous Routing.​

This week, I pushed my absolute limits as a Senior Software Engineer to solve a massive bottleneck in production AI deployments: token cost and model reliability.

Here is exactly what I designed, built, and shipped:

1️⃣ The OpenClaw Multi-Agent Routing Engine: Implemented a complex routing architecture supporting custom Model Context Protocol (MCP) servers. I built 6 specialized sub-agents running continuously 24/7 inside a single OpenClaw server, each completely owning an independent domain within the build and ship cycle.

2️⃣ Advanced Model Substitution (Ditching the Expensive Defaults): Instead of defaulting to heavy cloud APIs (like Claude Sonnet 4.6), I engineered multi-prompt MCP servers capable of executing repeatable, highly structured behaviors under tight circumstances.

3️⃣ The Results: By relying heavily on deterministic MCP code, we achieved identical operational performance to top-tier proprietary models while running on an open-source, modest backbone (GLM 5.1). Zero luxury cloud spend. Complete architectural independence.

This wasn't about writing basic API endpoints. This required deep architectural and decision-making orchestration around multi-agent prompting and state isolation. I had to build a system that manages multiple known operational scenarios flawlessly without forcing the core LLM to do the heavy cognitive lifting—keeping latency low and execution completely reliable.

If you aren't building runtime infrastructure that maximizes small, open-source models through hyper-engineered tooling, you're lighting your cloud budget on fire.

We don't wait for the future of agentic workflows. We ship it. 🛠️

Stop buying bloated 3rd-party software. Build what your architecture actually demands.​

This week, I didn't just ship features—I pushed my limits as a Senior Software Engineer by designing and launching custom AI-driven infrastructure to solve real organizational bottlenecks.

Here is a look at what went from my brain into production over the last 5 days:

🛠️ Custom AI RBAC System Instead of relying on rigid third-party access tools, I architected and built a native AI Role-Based Access Control (RBAC) application. It automatically reads and analyzes user permission levels, detects technical debt, and queues up precise fixes for engineering validation.

🌐 Advanced Model Context Protocol (MCP) Ecosystem I fully leaned into the MCP framework to supercharge our AI Agents:

• The Framework: Evaluated agent ecosystems and built a streamable HTTP MCP Server entirely in pure Node 24, replacing clumsy CLI commands with a robust package of REST API tools and custom prompts designed to aid weaker models.

• The Deployment Guardrail: Built an MCP Server that hooks directly into GitHub Actions. It assists AI agents in real-time configuration, troubleshooting, and deployment validations—enforcing strict, company-wide standards.

⚡ Multi-Cloud AI Clustering Architecture Designed and launched a Multi-Cloud AI Clustering MVP capable of running services across Kubernetes over disparate cloud providers, seamlessly connecting active AI agents to support the cluster.

The Reality Check: True senior engineering isn't about using the shiniest new model; it's about making AI work within constraints—building tooling that supports weaker models, automating manual deployment verification, and architecting custom solutions that eliminate external dependencies.

We don't wait for tools to be built for us. We build them.

What did you put into production this week?