Build Agent Configuration Across Multiple PDIs

Dinh Nguyen
Kilo Sage

Hi everyone,

We are currently evaluating Build Agent and would like to understand whether there is a way to maintain consistent Build Agent behavior across multiple PDIs.

Our goal is to ensure that developers working in different PDIs receive similar results and follow the same development standards.

We are considering two possible approaches:

Option 1: Shared Build Agent Configuration

  • Configure Build Agent in one PDI (settings, instructions, prompts, preferences, etc.).
  • Export or replicate that configuration to other PDIs.
  • This would allow all PDIs to use the same Build Agent setup.

Option 2: Shared Build Agent Across Multiple PDIs

  • Have multiple PDIs use the same Build Agent instance.
  • Ideally, common instructions, context, or behavior could be maintained centrally rather than configured individually on each PDI.

Has anyone implemented something similar, or is there an officially supported approach for standardizing Build Agent behavior across multiple PDIs?

Any guidance, documentation, or best practices would be greatly appreciated.

Please someone help me!

Thank you so much

1 REPLY 1

sanjaygupta
Tera Guru

There isn’t a documented way to have several PDIs share a single Build Agent instance, so Option 2 isn’t available as described. Option 1 is the supported direction, because standards are written as rules that live on each instance. For the best consistency, the documentation points to Developer Sandboxes on one shared instance rather than many PDIs.

For Option 1, Build Agent supports custom rules and skills. Rules are preloaded into every session automatically, and the documentation says to use them to enforce things like naming conventions, required fields or organizational standards. Skills are available on demand when you or the agent invokes them by name. Both can be set at the instance, application or user level, and creating them needs the admin role and Australia Patch 5 or later. The release post says they are stored as records on the instance.

To standardize this way:

  • Open the Settings icon in the Build Agent chat panel and use the Rules and Skills tabs.
  • Write your agreed development standards as instance-level rules on your main development instance.
  • Keep each instruction as clear, structured plain text. The limit is 65,000 characters per instruction.
  • Keep personal preferences at the user level so they don’t affect other developers.
  • Repeat the same rules on each PDI, or have PDI developers work in a shared environment instead (see below).

I did not find documentation confirming that these rule records can be exported and imported between instances, for example in an update set. Test that in a sub-production instance before relying on it, and keep the rule text in source control as the master copy.

PDIs also have limits that make consistency harder. Each PDI gets 25 prompts per 30-day cycle. The documentation says PDIs are updated to match the latest Build Agent version, so capabilities are the same, but each instance keeps its own rules.

Developer Sandboxes are the better fit for your goal. The documentation describes them as isolated environments with a controlled baseline configuration for parallel development on a shared development instance. Instance-level rules there cover every sandbox session on that instance, so all developers follow the same standards. The release post advises limiting instance rules to decisions the team has agreed, because every active rule uses context on every turn. It suggests ten deliberate rules rather than forty.

For the code itself, Build Agent tracks changes in update sets. Move those between instances through your normal update set or application repository process, with a test in sub-production first.

Sources: