Context Engineering: Wire Your Company Into AI

Start with one recurring task that produced a weak answer. Keep its original prompt and output. They anchor the search for context in real work and prevent the map from becoming an inventory of every tool your company owns.

Score each candidate system on four criteria. Decision density asks how much recorded evidence inside the system shapes the task’s outcome. Task relevance measures how directly that evidence answers the task. Freshness captures whether the records change often enough for live access to matter. Connection feasibility reflects the availability of a supported native connector or MCP route, plus a workable read-only permission model.

Use a simple 1–5 scale for each criterion. Write one evidence line beside every score. A number without a reason hides assumptions and makes ranking easy to manipulate. Where connector support, record coverage, or update frequency is unknown, mark it as an assumption to validate.

Rank the systems by total score, then apply judgment. High relevance and decision density should carry the most weight. Feasibility affects sequencing, yet an easy connection with thin context will rarely rescue the task. Select the three systems most likely to change the quality of the result.

Your context map identified the systems worth connecting. The next decision is narrower: define the smallest connection that gives the chosen task enough evidence to improve.

Start with a supported native connector when it provides the required source coverage, permissions, and audit controls. Use an MCP route when it is supported in your stack and offers a clearer or more controllable path. Connector availability, permission behaviour, and production readiness vary by vendor. Validate them before treating the route as real.

Every connection needs an exposure scope. This is a written boundary around what the AI may retrieve. Set access to read-only. Name the allowed workspaces, record types, fields, date ranges, or statuses. State exclusions just as precisely. “No sensitive data” is too loose to configure or review.

Scope against the failed task from Chapter 1. The model needs enough context to answer that task, rather than general visibility across the company. Define how retrieved material should identify its source and what happens when access fails. A confident answer without accessible evidence is still unsafe.

A connector earns its place through measured improvement. Use the failed task from your context map and the approved scopes from your connector plan. Preserve its original prompt, model, and relevant settings as the baseline. Then run it again with only the approved, read-only context available.

Comparability matters. If the prompt, model, success standard, or task inputs change between runs, you cannot tell whether connected context caused the difference. Record both outputs intact. Score them with the same simple rubric for output quality and factual grounding. Also capture completion time, unsupported claims, and missing source references. These reveal whether a polished answer is actually safer and more useful.

Judge the connection against the task, rather than expecting universal improvement. Choose keep when the connected run materially improves the agreed measures without crossing the exposure scope. Choose adjust when the route works but retrieval, permissions, or source selection needs tightening. Choose stop when improvement is absent, risk exceeds value, or the connector cannot respect the approved boundary.

A weak result does not automatically indict the model or the source system. It may expose a retrieval failure. Confirm that the intended records were visible and cited before deciding. Connector availability, controls, and logs vary by vendor, so validate those capabilities in your own stack and record any unverified assumption.