anda AGENTS.md

AGENTS.md

Guidance for AI coding agents working in this repository.

Scope

This file applies to the whole ldclabs/anda workspace. Follow more specific instructions in nested AGENTS.md files if any are added later.

Repository Shape

anda is a Rust workspace for composable AI agent runtimes.

• anda_core: stable traits, shared data models, context capabilities, JSON schema helpers, and RPC helpers.
• anda_engine: runtime orchestration, contexts, model adapters, tools, hooks, memory, subagents, and reusable extensions.
• anda_engine_server: HTTP server layer for exposing engines.
• anda_cli: CLI entrypoint for configured engine servers.
• anda_web3_client: Web3 integration for non-TEE environments.
• docs/architecture.md: source-level runtime architecture.
• MCP_INTEGRATION.md: MCP host/client design and boundaries.

Keep anda_core small and dependency-light. Runtime integrations belong in anda_engine or higher-level crates unless the shared contract genuinely needs to change.

Working Rules

• Inspect the exact code and docs relevant to the request before editing.
• Preserve user or agent changes already present in the working tree. Do not revert unrelated dirty files.
• Prefer small, behavior-focused changes over broad refactors.
• Keep public API changes coherent across code, docs, examples, and tests.
• Use workspace dependencies from the root Cargo.toml; do not add duplicate per-crate versions unless there is a clear reason.
• Keep generated schemas and protocol-visible names stable. Agent, tool, and provider names must satisfy the function-name rules: lowercase ASCII letters, digits, underscores, and hyphens, starting with a lowercase letter, max 64 bytes.
• When changing model/provider conversion code, preserve raw-history and tool/user message boundaries. Do not merge tool outputs into user messages or lose provider-specific content unless the existing code explicitly does so.
• ContentPart / chat_history is the persisted, provider-neutral history. Provider per-turn intermediate state (Anthropic thinking.signature, Gemini thoughtSignature) belongs in CompletionRequest::raw_history, which every adapter sends ahead of the converted chat_history and which is scoped to one in-process reasoning round. Do not add provider-specific fields to ContentPart to carry such state — an adapter dropping it on the way in is correct by design. Do fix the reverse: converting out of ContentPart must never emit something the provider rejects (e.g. a thinking block with an empty signature); omit it instead.