BYOC: org PUSHES context to the agent

At L3, context is pull-based: the agent discovers what it needs by querying MCP servers and reading files as it encounters them during task execution. This works, but it has a fundamental inefficiency - the agent spends early steps of every task assembling context that could have been provided upfront. Discovery-based context also introduces inconsistency: two agents working on similar tasks might retrieve different context depending on what they happen to query.

Bring Your Own Context (BYOC) inverts this model. Rather than the agent pulling context lazily, the organization actively pushes a pre-assembled context package to the agent when a task starts. Before the agent writes a single line of code, it receives: the current sprint goal and relevant tickets, the ownership graph for the services involved, recent architecture decisions that apply to this area, the current operational state of dependent services, any in-progress work in related areas, and the specific conventions that apply to this module.

This context package is assembled programmatically - not by a human writing a prompt, but by an automated pipeline that queries the organization's context sources (MCP servers, service registry, sprint planning tools, git history) and produces a structured, budget-respecting context bundle tailored to the specific task.

At L4 (Optimized), BYOC is part of the task dispatch infrastructure. When an agent is assigned a task (from a Jira ticket, a developer command, or an automated trigger), the context assembly pipeline runs first, producing the context package. The agent receives both the task and the context, fully loaded, and can begin reasoning about the solution immediately rather than spending its first steps on discovery.

BYOC addresses several limitations of pull-based context at scale:

• Eliminates discovery overhead - agents skip the context-gathering phase entirely and start working on the actual task immediately
• Ensures context consistency - all agents working on similar tasks receive the same organizational context, eliminating variance from different discovery paths
• Enables better context budgeting - the assembly pipeline can enforce budget constraints and prioritize context types before the agent session starts, rather than letting the agent's ad-hoc discovery fill the context window
• Reduces agent error rates - agents that start with complete, relevant context make fewer wrong assumptions in early steps that then propagate through the rest of the task
• Scales to agent fleets - when running hundreds of concurrent agent tasks, manual context assembly is not possible; BYOC makes automated, consistent context delivery achievable

The analogy is a surgical team: a well-organized operating room has all required instruments prepared and laid out before the surgeon arrives. The surgeon doesn't discover what they need during the procedure; it's pre-assembled by a team that knows what the operation requires. BYOC does the same for AI agents.

1. Catalog your agent task types - Identify the 3-5 most common agent task categories in your workflow (e.g., implement a Jira ticket, fix a failing test, refactor a module, investigate an incident). Each task type will have a characteristic context profile.
2. Map context needs per task type - For each task type, determine which context sources are always needed, which are usually needed, and which are rarely needed. This is your context assembly specification.
3. Build the assembly pipeline - Write a pipeline that takes a task identifier (ticket ID, module name, etc.) and queries the appropriate context sources (MCP servers, git history, service registry, sprint data) to assemble a context package.
4. Implement context budget enforcement - The assembly pipeline should produce a context package that fits within your target token budget. Implement prioritized truncation: if the budget is exceeded, drop lower-priority context before higher-priority context.
5. Inject the context package at session start - Configure your agent orchestration to prepend the context package to every agent session for that task type. The agent should receive the context as part of its initial prompt, not as files it discovers later.
6. Measure and iterate - Compare agent task success rates and iteration counts before and after BYOC. The expected improvement is fewer iterations to success (lower ITS metric) and higher first-attempt success rates.

Building a monolithic context package that's too large. If your BYOC pipeline assembles everything potentially relevant and dumps it into the context window, you've recreated the "more is better" fallacy in automated form. The assembly pipeline must be selective - include what's needed for this task type, not everything that might conceivably be relevant.

Not updating the assembly pipeline when context sources change. If your organization adds a new service registry, changes the format of sprint planning data, or decommissions an MCP server, the BYOC pipeline needs to be updated. Treat the pipeline as production infrastructure with monitoring and ownership.

Ignoring staleness at the assembly layer. A BYOC pipeline that assembles context once at task start and doesn't refresh it for long-running tasks will give agents stale operational context as the task progresses. Build in refresh hooks for operational context (deployment status, incident state) that updates the agent's context during execution.

Skipping the pull-based (L3) foundation. BYOC is efficient because it automates what pull-based context discovery does manually. If you haven't built the MCP servers and context sources at L3, there's nothing for the assembly pipeline to query. BYOC is an optimization of L3 infrastructure, not a replacement for it.