Company context: org structure vs. how work actually happens

The org chart is a useful fiction

Every company has an org chart. It shows boxes and lines: who reports to whom, which teams exist, how departments roll up to divisions. It is necessary for governance, compensation, and compliance. It is also a deeply incomplete description of how the organization operates.

At a 10,000-person technology company, the org chart says the data science team sits under the CTO. It does not say that this team collaborates more frequently with the marketing analytics group than with any other engineering team. It does not say that approval for headcount in APAC requires sign-off from the regional GM and the global function lead, while headcount in EMEA only needs the function lead. It does not say that the company runs a 90-day probation policy in Germany but a 6-month policy in Japan due to local labor law.

These are not edge cases. They are how the company works. And an agent that does not understand them will make recommendations that are structurally wrong.

Three layers of company context

Company context operates on three layers, each essential for agent decision-making.

Layer	What it includes	Example
Structural	Team composition, reporting lines, cost centers, location footprint	The London office has 3 product teams but shares a single design resource with Berlin
Operational	Policies, approval workflows, business rules, compliance requirements	Internal transfers require 12 months in current role; exceptions need VP approval
Behavioral	Collaboration patterns, decision-making norms, communication preferences	The sales team operates on Slack; the legal team uses email; cross-functional projects use Teams

Structural context: who sits where and why it matters

Structural context goes beyond the org chart to capture how teams are actually composed and how resources are shared. When Fatima Al-Rashidi, an HRBP supporting the product organization, asks the agent to identify candidates for a new technical program manager role, the agent needs to know more than reporting lines.

It needs to know that the product org has a matrix structure where program managers serve two masters: the product VP for priorities and the engineering VP for technical standards. It needs to know that the Singapore team operates semi-autonomously with different sprint cadences. It needs to know that three contractors are filling roles that were approved as full-time headcount but never converted.

Structural context makes the difference between a recommendation that looks right on paper and one that works in practice.

Operational context: the policy mesh

Every organization runs on policies. Some are global. Some are regional. Some are written. Some are not. The agent needs all of them.

Consider internal mobility. A straightforward concept until you look at the details. At one global bank, the policy varies by business unit: retail banking requires 18 months in role before transfer eligibility, while technology requires only 12 months. Transfers across divisions need the sending manager, receiving manager, and divisional HR lead to approve. Transfers within a division need only the two managers. And there is an unwritten norm that transferring during Q4 close is strongly discouraged in the finance function.

An agent recommending an internal move to Carlos Mendes in corporate finance during November needs to understand all of this. Not just the written policy. The full operational reality.

Behavioral context: how work actually flows

Behavioral context captures the patterns that no policy document describes. Which teams collaborate frequently? Where do decisions actually get made versus where the process says they should? What communication channels does each group prefer?

This layer is built from collaboration data: project co-assignment, meeting patterns, cross-team Slack or Teams interactions, shared document activity. When the agent sees that Yuki Tanaka in Tokyo engineering and David Okafor in Lagos product design have co-authored 14 documents in the past quarter, it understands a collaboration relationship that no org chart reflects.

Behavioral context is also what prevents agents from making tone-deaf recommendations. Suggesting a Slack-based onboarding workflow to a team that operates entirely in email is not just inefficient. It signals that the system does not understand the organization. That kind of misalignment destroys trust fast.

Why company context must be unique per customer

This is a critical architectural point. People context follows broadly similar patterns across companies: every organization has employees with skills, trajectories, and aspirations. But company context is singular. No two companies have the same policy mesh, the same collaboration patterns, or the same operational norms.

A pharmaceutical company with 50,000 employees in 40 countries has a company context that is fundamentally different from a 5,000-person technology startup with three offices. The policies are different. The approval chains are different. The collaboration patterns are different. The compliance requirements are different.

This means company context cannot be templated or generalized. It must be learned from each customer environment, continuously updated as policies change and collaboration patterns shift, and deeply integrated into every agent decision.

Generic recommendation	Company-context-aware recommendation
“Consider lateral moves in product management”	“The APAC product team has an open TPM role. Your collaboration history with that team is strong, and the 12-month tenure requirement is met. The hiring manager, Sanjay Gupta, has approved sourcing from internal candidates.”
“You may be at risk for attrition”	“Based on comp benchmarks for your cost center in the Berlin office, your salary is 11% below the local market midpoint. The EMEA comp adjustment window opens in 6 weeks.”

The difference between generic and context-aware is the difference between a suggestion and an action. Company context is what bridges that gap.