Skip to main content
Every project that uses the Kodexa Agent has a companion configuration — the runtime that powers the chat, an optional custom prompt, and the modules the agent can call. You manage this from Project Settings → Companion.
The companion configuration is per-project, but most settings fall back to an organization-level default. You only need to override what is specific to this project.

​
Where To Find It

From inside a project workspace:
  1. Open Project Settings (gear icon in the project header).
  2. Select the Companion tab.
You will see three groups of settings: the runtime, the custom prompt, and the module bindings.

​
Pick A Runtime

The agent runtime is the container image that runs your conversations. Your org admin publishes one or more runtimes; each one is identified by a slug like kodexa/claude-code-agent or acme/finance-agent.
  • If a runtime is set at the organization level, every project inherits it by default. Leave the project field blank to use the default.
  • To override for this project, pick a different runtime from the dropdown. This is useful when one project needs a specialized runtime (for example, a runtime built around a finance module set).
Runtimes themselves are managed by org admins. If the runtime you need is not in the list, ask your admin to publish or share it.

​
Write A Custom Prompt

The custom prompt is a project-specific system instruction that the agent reads on every turn. Use it to teach the agent things that are true for this project and would otherwise need to be repeated in every message. Good things to put in a custom prompt:
  • Project-specific terminology (“when we say ‘vendor’, we mean the supplier on the invoice, not the customer”).
  • Business rules that should always apply (“invoices over $50,000 require a second reviewer”).
  • Conventions for naming (“name new taxons in lower_snake_case”).
  • References the agent should prefer (“when extracting line items, use the line_item structural type”).
Things to keep out of the custom prompt:
  • Secrets, API keys, or credentials. The prompt is visible to the agent on every turn — and to anyone with access to the project’s settings.
  • Long, exhaustive instructions. Keep it short and high-signal; the agent already has access to project context.

​
Bind Modules

A module binding exposes a Kodexa module to the agent as a callable tool. When the agent decides a module is the right way to fulfill a request, it can invoke it the same way a person clicking through the UI would. Use module bindings when you want the agent to:
  • Run a custom extractor against a document on demand.
  • Call into a domain-specific function your team has packaged as a module.
  • Trigger an integration that lives in a module rather than a service bridge.
Each binding gives the agent permission to call that module on your behalf. Bind only what the agent needs.

​
Org Default vs Project Override

A useful pattern:
  • Set an organization-level runtime that covers 80% of projects. Leave the project Companion tab untouched on those projects.
  • Override per project only when a project has unusual needs: a domain-specific runtime, a long custom prompt, or modules that exist only for that workflow.
This keeps configuration simple to reason about — most projects inherit the same agent, and you only see overrides where they matter.

​
Saving Changes

Click Save to apply changes. The next time someone opens the chat pane in this project, the agent will pick up the new configuration. Existing open chat sessions may need to be reloaded.