feat(config): support shared Dockerfile via buildContextPath and customDockerBuildArgs in agentcore.json

[EdouardCourty]

Description

Currently, declaring multiple runtimes in agentcore.json effectively requires one Dockerfile per agent (via the dockerfile key). This forces users to maintain several nearly-identical Dockerfiles when the build logic is shared.

Current config example:

{
  "name": "dummyagent",
  "build": "Container",
  "entrypoint": "dist/main.js",
  "codeLocation": ".",
  "dockerfile": "Dockerfile.dummy-agent",
  "networkMode": "PUBLIC",
  "protocol": "HTTP"
},
{
  "name": "generalchat",
  "build": "Container",
  "entrypoint": "dist/main.js",
  "codeLocation": ".",
  "dockerfile": "Dockerfile.general-chat",
  "networkMode": "PUBLIC",
  "protocol": "HTTP"
}

Two additions to the runtime config schema would enable sharing a single Dockerfile across all agents:

1. buildContextPath — explicit Docker build context

Add a buildContextPath key to specify the Docker build context directory independently from codeLocation. This mirrors the standard docker build -f <dockerfile> <context> syntax and gives users fine-grained control over what is sent to the daemon.

2. customDockerBuildArgs and/or automatic AGENT_NAME build arg

Either (or both):

• Automatic injection: always pass AGENT_NAME=<runtime.name> as a --build-arg so the Dockerfile can branch on it without any extra config.
• Declarative args: allow a customDockerBuildArgs map in the runtime config that is forwarded verbatim as --build-arg flags to the Docker build command.

Proposed config with both additions:

{
  "name": "dummyagent",
  "build": "Container",
  "entrypoint": "dist/main.js",
  "codeLocation": ".",
  "dockerfile": "Dockerfile",
  "buildContextPath": ".",
  "customDockerBuildArgs": { "AGENT_NAME": "dummyagent" },
  "networkMode": "PUBLIC",
  "protocol": "HTTP"
}

Or, with automatic AGENT_NAME injection, the Dockerfile side would look like:

ARG AGENT_NAME
# ... shared build steps ...
COPY dist/${AGENT_NAME} ./app

Acceptance Criteria

• A buildContextPath key is recognised in a runtime entry and used as the Docker build context (equivalent to the positional argument in docker build -f <file> <context>)
• At least one of the following is supported:
  • customDockerBuildArgs map in the runtime config, forwarded as --build-arg flags
  • Automatic injection of AGENT_NAME (set to runtime.name) as a build arg
• Multiple runtimes can share a single Dockerfile, each producing a different image based on build args
• Existing configs without these new keys are unaffected (fully backwards-compatible)

Additional Context

This is particularly useful in monorepo setups where several agents share the same base image and build process, differing only in their entry point or bundled code. Without this, every new agent forces a new Dockerfile, which creates duplication and maintenance overhead.