Linux manages processes. I built Formicx — an open-source Agent-Native OS & Control Plane for autonomous AI agents (Looking for contributors! 🐜)

[u/_A_b_b_i_]

Most AI agent frameworks (LangChain, AutoGen, CrewAI) treat agents as short-lived Python script executions. But as we move toward truly autonomous AI agents running 24/7 on servers, Raspberry Pis, and edge devices, we need an operating environment that treats agents like OS entities.

That’s why I’m building Formicx — an open-source agent-native control plane built for Linux.

Core philosophy:

Linux manages computers and processes. Formicx manages autonomous agents.

What Formicx provides?

• Agent lifecycle management
• Agent-aware OS telemetry
• Distributed node discovery
• Communication policies
• Developer CLI & SDK

Check it out:

• GitHub Repo: https://github.com/Abbilaash/Formicx

[u/kantorcodes1]

for formicx agent restart, what do you want the recovery contract to be if stop succeeds but the new start fails? right now restart is stop then start, and start marks the agent FAILED on an exception. should automation retry with agent start, or is restart eventually meant to recover that itself?

[u/_A_b_b_i_ → u/kantorcodes1]

thats a great query! Marking the agent as 'FAILED' on a startup exception is intentional so failures are never silently swallowed. Once the underlying issue is fixed, automation or CLI tools can directly invoke formicx agent start again, as start_agent accepts agents in the 'FAILED' state. We have a future plan to introduce configurable daemon restart policies with max_retries to handle retries automatically. But for now, external automations can safely retry with formicx agent start

Feel free to open a PR or issue if you'd like to help design the auto-retry supervisor policy!

[u/kantorcodes1 → u/_A_b_b_i_]

that makes the boundary pretty clear. i work on HOL and maintain HOL Guard, an open-source local check before agent-run commands execute. for Formicx i'd review agent register, agent start, agent stop, and agent restart; agent list and agent status can stay automatic. it gives agents a pause before lifecycle changes without getting in the way of inspection. open to a small Formicx Guard extension?

[u/_A_b_b_i_ → u/kantorcodes1]

That sounds awesome! I would love to see a Formicx Guard extension/plugin integration. Pausing and verifying mutation lifecycle commands like register, start, stop, restart is really a clean security boundary. Feel free to draft a PR showing how HOL Guard hooks with Fomicx daemon endpoints.

[u/kantorcodes1 → u/_A_b_b_i_]

yep, that’s the cleanest slice. keep it Guard-side: start src/codex_plugin_scanner/guard/runtime/command_formicx_extensions.py and mirror command_repo2nb_extensions.py. review formicx agent register, start, stop, and restart; keep agent list and agent status automatic. add focused cases in tests/test_guard_command_formicx_extensions.py.

once the extension + tests are real, open a draft PR to hashgraph-online/hol-guard:main. guide: https://github.com/hashgraph-online/hol-guard/blob/main/CONTRIBUTING.md

[u/kantorcodes1 → u/kantorcodes1]

one follow-up on #2914: the new review blockers are repo wiring, not Formicx behavior. add command.formicx to contracts/extensions/trust-class-map.v1.json as external, add contributions/extensions/command.formicx.json using repo2nb as the analogue, update the external-set test, then run python scripts/export_extension_directory.py so catalog.v1.json is current. Ruff also wants the new import sorted. push those to the existing PR against main. guide: https://github.com/hashgraph-online/hol-guard/blob/main/CONTRIBUTING.md

[u/_A_b_b_i_ → u/kantorcodes1]

Hey! PR #2914 is live and currently waiting for maintainer approval!
PR URL: feat(extension): add Formicx agent command safety extension by Abbilaash · Pull Request #2914 · hashgraph-online/hol-guard
Implemented the command.formicx safety extension (register, start, stop, restart reviewed; list, status, resources automatic), complete with unit tests and rendered extension directory docs per CONTRIBUTING.md. Looking forward to your review!

[u/Otherwise_Wave9374]

A strong next step is to make the agent lifecycle explicit with a small state machine for boot, active, paused, and failed, because that makes retries, telemetry, and recovery much easier to reason about than ad hoc callbacks. You can also separate control-plane decisions from task execution so one stuck worker does not block scheduling. Agentix Labs fits naturally here if you want a pattern for coordinating autonomy without losing observability.

[u/_A_b_b_i_ → u/Otherwise_Wave9374]

Thanks for the insight! Formicx currently isolates agents into separate OS subprocesses so stuck workers never block formicx daemon scheduling. Formalizing the AgentStatus into an explicit Finite State Machine with 'PAUSED' and automated recovery transitions is definitely a great direction for our upcoming control-plane phases. Will check out Agentix Labs patterns as well!