Problem or motivation
All agent parameters (LLM vendor, model, credentials path, log level, toolsets, compile output directory, signing and verification keys) must currently be specified programmatically when instantiating an agent. This makes it impossible to version-control a project's configuration and forces users to couple configuration concerns with application code.
Proposed solution
Support a nemantix.toml file at the project root (or a [tool.nemantix] section in pyproject.toml) as the canonical configuration source for a Nemantix project. For example:
[agent]
vendor = "anthropic"
model = "claude-sonnet-4-6"
credentials = "creds.json"
log_level = "INFO"
[agent.toolsets]
PizzaToolset = "myapp.toolsets.pizza"
"*" = ["myapp.toolsets"]
[compile]
output = "build/"
[sign]
key = "keys/private.pem"
[verify]
key = "keys/public.pem"
NXS example (if applicable)
Alternatives considered
Currently, environment variables only, but this approach is insufficient because they are not version-controllable and do not support structured values like toolset declarations.
Additional context
Toolset resolution from configuration is a prerequisite for any future CLI integration: without a standard way to declare which toolsets a project uses, a CLI runner would have no way to load them automatically at startup (or would have to explicitly require a special parameter at every run).
Problem or motivation
All agent parameters (LLM vendor, model, credentials path, log level, toolsets, compile output directory, signing and verification keys) must currently be specified programmatically when instantiating an agent. This makes it impossible to version-control a project's configuration and forces users to couple configuration concerns with application code.
Proposed solution
Support a
nemantix.tomlfile at the project root (or a[tool.nemantix]section inpyproject.toml) as the canonical configuration source for a Nemantix project. For example:NXS example (if applicable)
Alternatives considered
Currently, environment variables only, but this approach is insufficient because they are not version-controllable and do not support structured values like toolset declarations.
Additional context
Toolset resolution from configuration is a prerequisite for any future CLI integration: without a standard way to declare which toolsets a project uses, a CLI runner would have no way to load them automatically at startup (or would have to explicitly require a special parameter at every run).