docs: add Atomic Agent to integrations

[sosidudku1]

Description

Hi! I'm the CPO of Atomic Agent. Thanks for this great project and for keeping the integrations page so well organized. Our team would be thrilled to be listed.

Atomic Agent is a local-first CLI and TUI coding assistant (MIT, ~2k stars). It has a generic openai-compatible provider kind, so a LocalAI instance can be used as its model backend by pointing it at LocalAI's OpenAI-compatible endpoint. To be precise about the fit: we do not ship a dedicated LocalAI preset, and Atomic Agent is not built on LocalAI. This is the same "point it at the endpoint" integration that the existing OpenCode and Crush guides describe.

This PR adds two things, following the existing structure of the page:

1. A row under Terminal Tools, matching the surrounding - [Name](link) - Description format.
2. A configuration guide under Configuration Guides, placed after Charm Crush and modeled on the OpenCode / Claude Code / Crush guides.

One detail the guide calls out explicitly, because it is an easy way to get a broken setup: unlike the OpenCode and Crush configs on this page, the Atomic Agent baseUrl must not include the /v1 suffix. Atomic Agent appends /v1/... to the base URL on every call, so including it produces requests to /v1/v1/chat/completions.

I also noted in the guide that Atomic Agent is currently a developer preview, since its APIs, commands, and config are still moving. That is stated in our own README and it seemed more useful to your readers to say it up front than to leave it out.

Notes for Reviewers

• Docs-only change. One file touched: docs/content/integrations.md. No code, no build changes.
• Everything in the guide was verified against the current Atomic Agent source rather than written from memory:
  • the openai-compatible provider kind is registered in src/llm/provider/registry/register-built-in-providers.ts and requires baseUrl + defaultChatModel
  • /v1/chat/completions and /v1/models are appended to baseUrl by the provider, which is what the no-/v1 note is based on
  • the config path ~/.atomic-agent/config.json and the llm.providers[] shape match the config schema
  • the OPENAI_COMPAT_API_KEY env var is read in src/config/resolve-llm-api-key.ts
  • the TUI model picker fetches {baseUrl}/v1/models, which is why the guide mentions it as an alternative to hand-editing JSON
• The example model ID (qwen_qwen3-4b-instruct-2507) is one already used elsewhere on this same page, so it is a real gallery model.
• The JSON snippet was parsed to confirm it is valid.

A note on the Assisted-by trailer

This change was prepared with AI assistance, so per .agents/ai-coding-assistants.md the commit carries an Assisted-by: Claude:claude-opus-5 trailer and deliberately carries no Signed-off-by and no Co-Authored-By trailer from the assistant. I understand the sign-off is mine to add as the human submitter, and I am happy to amend the commit with my own Signed-off-by if you would like the DCO line on it. Just say the word and I will push it.

Signed commits

• Yes, I signed my commits.
• Documentation updated (docs/content/) for user-facing changes, or not applicable

Happy to adjust the wording, trim the guide down to just the list entry, or move it to a different section if you would prefer. Thanks for taking a look!

[mudler]

Thanks @sosidudku1 for the suggestion. We add integrations that explicitly list LocalAI as compatible, which I could not find in the atomic agent documentation: https://atomicagent.io/docs/guides/ollama/#_top

[localai-org-maint-bot]

Checked the documented Atomic Agent configuration keys and provider kind against its current source (activeTextProvider, openai-compatible, baseUrl, defaultChatModel, apiKey, and OPENAI_COMPAT_API_KEY). The LocalAI URL guidance is consistent with the integration. @mudler good to merge from my side.