← Back to Docs
Configuration

Configure tools so capabilities and costs stay clear

Tools define what actions agents are allowed to execute. In QuantenRam, they only create real value when the capability set, model tier, and cost expectations are cleanly aligned. It's not about having many tools, but about consciously selecting which ones to enable.

The most practical configuration starts with a few clear capabilities. Each tool represents a specific action—file operations, network access, code execution, or external API calls. For teams, this means creating not just a technical list, but an operational contract that determines who can do what and at what cost.

Enable only required tools

Tools should be consciously enabled, not enabled by default. Each additional tool increases the attack surface and can drive up costs if an agent takes unexpected actions. In QuantenRam, you should only enable the tools that are actually needed for the current task.

Protect sensitive operations

Tools with write access, deletion capabilities, or network requests require special attention. They should either be behind explicit confirmation prompts or limited to specific paths and endpoints. This is especially important when agents work autonomously.

Keep tool outputs auditable

What a tool does should be reconstructible later. In QuantenRam, tool usage appears in Activity along with the associated costs. This transparency is essential for teams to understand which tools actually deliver value.

Tool selection and tier mapping

Not every tool should use the most expensive model tier. Reading tools can often run on Start models, while complex code analysis should be escalated to Coding or Zenmaster. This tier-aware selection saves costs without compromising quality.

// Example: Tool configuration with tier mapping
{
  "tools": {
    "file-read": {
      "model": "quantenram-start/glm-5",
      "scope": ["./src", "./docs"]
    },
    "file-write": {
      "model": "quantenram-coding/qwen3codernext",
      "confirmation_required": true
    },
    "web-search": {
      "model": "quantenram-start/deepseek-chat",
      "rate_limit": "10/minute"
    }
  }
}

The key to this configuration is the conscious mapping of tools to model tiers. The file read tool stays cheap because it's a routine operation. The write tool gets a stronger model for better code generation but requires confirmation. The web search tool has a rate limit to control costs.

Tool boundaries and fallback behavior

Good tool configurations define not just what is allowed, but also what happens when boundaries are exceeded. If a tool reaches a limit—whether it's file size, execution time, or cost—it should respond cleanly with a fallback, not an unhandled error.

// Fallback configuration for tool limits
{
  "file-read": {
    "max_size": "1MB",
    "on_limit_exceeded": "summarize",
    "fallback": "read-first-100-lines"
  },
  "code-execute": {
    "timeout_seconds": 30,
    "on_timeout": "terminate-with-log",
    "max_memory_mb": 512
  }
}

In QuantenRam, you can configure these limits at the tool level. They act as guardrails that prevent runaway costs or unexpected behavior. When a limit is hit, the fallback behavior kicks in, allowing the agent to continue working rather than failing completely.

Tools are force multipliers when configured well. They become liabilities when enabled carelessly. Invest time in defining clear boundaries and fallbacks—your future self and your team will thank you.