From Wiki to Execution: Making Organizational Knowledge Work for AI Agents

The previous article discussed how business intent, design, plans, code, and evidence form a continuous artifact chain. Even with authoritative artifacts, teams face a practical problem: rules written in wikis, handbooks, and architecture documents are still violated by agents—layer constraints are ignored, tests are skipped, sensitive configuration ends up in code.

The root cause is not insufficient prompt length; organizational knowledge has not entered the agent's actual execution path.

Documents Exist, But Don't Guarantee Execution-Time Effectiveness

Consider a batch-import case. The team has rules: large files must be processed asynchronously, database writes must be batched, raw files must not enter logs, all interfaces require permission checks, new table structures need rollback migrations. These rules are scattered across architecture specs, security manuals, and project wikis. The development agent receives only the task "implement batch import," reads current module code and a functional design, then generates a synchronous upload endpoint, parses the entire Excel in the request thread, and logs failed rows in full.

From the model's perspective this implementation may look reasonable. It simply does not know which knowledge is mandatory for the current project, nor which rules must block a commit if violated. Therefore, organizational knowledge must be layered by how it takes effect, not stuffed into an ever-growing project description.

Project Context, Skills, Hooks, and Gates Solve Different Problems

By mode of action, rules entering the agent execution process can be grouped into five constraint mechanisms:

Project Context – lets the agent understand the current system, boundaries, and ways of working. Example: module responsibilities, build commands, directory conventions, authoritative design locations.

Skill – reuses organizational experience that requires judgment and step orchestration. Example: how to design async tasks, how to verify database migrations.

Hook – deterministically triggers actions on specific events. Example: automatically run migration checks after a database script changes.

CI Gate – runs non-bypassable checks on code and artifacts. Example: build, test, dependency scanning, contract compatibility checks.

Platform Policy – enforces permissions and resource boundaries in the runtime environment. Example: prohibit long-lived production credentials, restrict sandbox network and data access.

A Skill is not a monolithic prompt but a repeatable knowledge unit that specifies applicability conditions, inputs, steps, outputs, and verification methods. A Hook acts as an event trigger that runs deterministic actions on file changes, command execution, or task state changes.

These layers are not replacements. Project context and skill descriptions influence how the agent understands and acts—still soft constraints. Parts that must be enforced should sink into scripts, hooks, CI, or platform policies to check and limit actual behavior.

What Should Go into Project Context

Project context holds stable facts every new member and agent must know before starting work:

What problem the system solves and what the current module owns.

Where the authoritative sources for requirements, designs, and interfaces live.

Which build, test, and lint commands to use.

Which directories are editable and which generated artifacts must not be hand-edited.

How to handle design gaps, environment blocks, and high-risk changes.

What evidence satisfies the definition of done.

These statements should be short, specific, and point to authoritative materials. Copying the entire architecture history and coding standards into project context increases context cost and introduces stale rules. Project context answers "what to know first when entering the project" and is not suited to carry all domain methods and security policies.

What Organizational Experience Deserves to Be a Skill

A piece of knowledge merits a Skill if it is reused repeatedly, contains stable steps, and requires limited judgment based on context.

Designing state and recovery for async import tasks – identify business end states and failure strategies, define task states, idempotency boundaries, checkpoints, retries, and human-in-the-loop entry points, then output a checklist and open questions.

Verifying database migration releasability – read migration scripts and target database constraints, check lock risks, compatibility windows, rollback or forward-fix plans, and require real-environment drill evidence.

Skills must not silently become decision-makers. They can propose candidates, identify gaps, and execute authorized steps, but cannot decide whether partial success is acceptable or accept data-migration risk on behalf of the business owner.

Constraints That Can't Rely on Model Judgment Must Go to Deterministic Mechanisms

Some rules, no matter how clearly written, cannot depend on the agent's voluntary compliance.

Secrets and sensitive configuration, database migrations, core regressions, API compatibility, production credentials, and protected branches should be enforced by hooks, static analysis, CI, branch protection, or platform permissions. The agent may explain failures and suggest fixes, but cannot bypass checks by tweaking prompts or declaring exceptions in completion reports.

Deterministic mechanisms are not infallible—rules can become outdated or produce false positives—but their execution results must be repeatable, auditable, and have exceptions managed by authorized roles.

Rules Also Need Clear Maintenance Ownership

Once rules enter agents and pipelines, they affect every task. A bad rule can propagate faster than bad code.

Every organizational rule must answer at least:

Who maintains and interprets it.

Which projects, versions, and risk levels it applies to.

Who reviews changes before they take effect.

How to verify it won't block legitimate scenarios.

Who approves exceptions and when exceptions expire.

How the rule retires instead of accumulating forever.

Architecture teams can own layering and dependency rules, security teams own credential and sensitive-data baselines, platform teams provide unified enforcement capabilities, and service teams own concrete business rules and runtime outcomes. Handing all rules to the platform team often yields technically strict but business-unusable gates.

Agent Configurations and Skills Are Also Mutable Software Assets

Many teams rigorously test business code but modify agent instructions, skills, and hooks and immediately enable them across all projects.

These configurations change execution behavior too. For example, updating a batch-import skill's default "retry on failure" suggestion may cause the agent to repeatedly submit when external side-effects are unknown; adjusting a hook's match pattern may miss a class of migration files.

Therefore they also need:

Versioning and change logs.

Representative tasks and edge cases.

Expected outputs and prohibited behaviors.

Regression validation in controlled environments.

Canary rollout, rollback, and impact observation.

Eval here means continuous evaluation of agent behavior—not just comparing answer text, but checking whether the correct baseline was read, allowed tools were called, stop conditions were honored, and required evidence was produced. This article validates the agent configuration and execution rules themselves; whether the concrete business implementation is correct requires the independent verification system discussed in the next article.

A Minimal Way to Land Organizational Knowledge

Small teams don't need a full skill marketplace and policy center upfront. Start with four steps:

At the project entry point, document system boundaries, authoritative artifacts, common commands, and stop conditions.

Package repeatedly used, judgment-requiring methods into a few skills.

Put hard constraints—secrets, build, test, compatibility—into automated checks.

Keep versions and a handful of real regression scenarios for rule changes.

Let one real task complete stably under these constraints, then decide which knowledge deserves platformization.

Summary

Organizational knowledge cannot stay only in wikis, nor become a single giant system prompt.

Project context states current facts, skills reuse organizational methods, hooks and CI run deterministic checks, platform policies limit permissions and blast radius. Together they form the agent's controlled execution environment.

The next article will discuss the verification results produced by this environment: why, even after the agent runs tests, it still cannot be the one to declare the results trustworthy.