The Full Context Product: How Agentic AI Eliminates the Teams We Built to Hold Software Together

A "full context product" is one whose operational complexity exists not in its technical architecture but in the accumulated human knowledge surrounding it — the institutional memory of edge cases, stakeholder expectations, and undocumented workarounds that keeps it functioning. Strip away the people who hold that context and the product fails, regardless of how simple the underlying technology actually is.

A variation on the dark factory thesis. Humans remain, humans are accountable, and what changes is everything else.

1. The Team That Memory Built

There is a certain kind of organisational structure that forms not by design but by accumulated necessity. Take a low code onboarding system. It changes twice a year. It breaks twice a week. And somehow, over time, a team of twenty people has grown up around it. Not because the product is complicated, not because the work genuinely requires twenty people, but because the knowledge of what the product is, what it means, what it is supposed to do, and who notices when it goes wrong lives entirely in those twenty people. Remove them and the product collapses, not from technical failure but from contextual amnesia.

This is the team that memory built. And we keep building them, product after product, system after system, because we have never found a better way to hold context than the human mind. Until now.

2. What the Dark Factory Gets Right, and Where This Model Diverges

The dark factory concept argues that production floors can operate without humans when the environment is sufficiently understood and sufficiently automated. Lights off. No bodies required. I have extended this idea into software and described how AI agents can run systems with no permanent human presence needed. The logic is clean: if machines can hold the context, machines can run the shop.

The Full Context Product is a related but meaningfully different idea, and the distinction matters enough to state plainly. This is not a dark factory. Humans make every change to the product. Humans are accountable for every output the system produces. The agentic layer does not replace human judgement or human accountability. It equips humans to exercise that judgement across a far broader surface area than was previously possible. Employees are still employees. What changes is the infrastructure they work inside.

What this model removes is not humans but assignment. The permanent, product specific team whose identity and institutional purpose is bound up in a single capability disappears. That coupling is the problem, not the people. Agents execute within a context that humans define and own. The human who picks up a product under this model is not supervising an autonomous system. They are a skilled professional working with much better tools, much better documentation, and much better memory than the profession has ever had access to before.

3. Contracting Context In, Not Hiring It In

The Full Context Product is built around a principle that changes everything about how we staff and operate technology: context must be contracted in, not hired in.

When a product joins the organisation under this model, the first work is not building a team. It is building a context. Five planes of that context must exist and must be maintained.

The compliance context defines what rules govern this product: what regulations, internal policies, audit requirements, and risk thresholds shape acceptable behaviour. This is expressed formally and maintained agentically so that any change to the product can be validated against it without someone having to remember what the rules were last time. PII handling sits explicitly within this context: what personal data the product touches, where it is held, under what retention and access constraints, what constitutes a violation of those constraints, and what the notification and remediation obligations are if something goes wrong. PII is not a footnote to compliance. In most regulated industries it is the centre of it, and it belongs in the contract from day one.

The cyber context defines the security posture of the product. This is distinct from compliance. Compliance tells you what the rules are. Cyber context tells you what the threats are and what controls are expected at each boundary. It covers the attack surface of the product, authentication and authorisation boundaries, secrets management, dependency risk, data in transit protections, and what constitutes a security regression. A change that degrades the security posture of the product should be as visible and as deliberately decided as a change that breaks a functional behaviour, and without a cyber context contracted in, it will not be. This context also owns the relationship between the product and the organisation’s broader security tooling, covering SIEM integration, alerting thresholds, and the observability gaps that would otherwise go unnoticed until an incident surfaces them.

The testing context is where the sharpest conceptual shift lives. Tests here are not primarily about finding bugs. They are about preserving deliberate behaviour. Every subtle, contextual, intentional behaviour of the product is contracted in with a test that states: this is what this product is supposed to do in this situation. Changes and bugs are caught not because someone runs a regression, but because the system knows what was meant. This also raises a specific governance question in an agentic environment: when an agent proposes or makes a change that touches the behavioural contract, a human must explicitly approve the update to that contract. The agent does not self-authorise changes to the definition of correct behaviour. That approval is a human act, and it is where accountability is most concretely exercised.

The UI context means the visual and interaction grammar of the product is defined and held as a living reference, not a design file sitting on someone’s laptop. The agentic layer can read it, validate against it, and extend it consistently regardless of who is doing the work.

The user change management context ensures that as the product evolves, users can absorb those changes without being overwhelmed. This context defines how change is communicated, what the tolerance for change looks like across different user segments, and what support is needed to move people through transitions. The agent manages this proactively, not after the fact when the support queue starts climbing.

With all five contexts established, the product carries its own memory. It knows what it is. It knows what it should do. It knows what governs it, what threatens it, and what its users need. And it can surface that knowledge to whoever is working on it at any given moment, whether that person has worked on it before or not.

4. The Agentic Layer as Product Manager

In a traditional product team, the product manager holds the thread. They carry the history of decisions, the rationale behind trade-offs, the map of what was tried and abandoned, and the understanding of what the business actually needs versus what was formally asked for. That knowledge is intensely personal and almost impossible to transfer cleanly when someone leaves or moves on.

In the Full Context Product, that role belongs to the agentic layer. Not because AI replaces product thinking, but because AI is now capable of holding and surfacing context at a fidelity and consistency that no individual human can sustain across time, team changes, and competing pressures. The agent knows the intent behind each feature because that intent was contracted in at the point of definition. It knows the compliance boundaries, the cyber posture, and what behaviour is deliberate and must be preserved versus what is incidental and can be changed. It knows what the last ten changes were, what tests they touched, and what the risk profile looked like. When a developer picks up work on this product for the first time, or the first time in eighteen months, that context is surfaced immediately and completely.

This is not about AI making product decisions. It is about AI making it possible for any competent human to make well informed product decisions on any product, at any time, without needing a two week handover from someone who is leaving.

5. Accountability and Execution Are Not the Same Thing

A May 2026 Harvard Business Review study by Kropp, Bedard, Wiles, Hsu, and Krayer offers research that is directly relevant here, and it is worth engaging with it specifically rather than treating it as a general caution. Their randomised experiment found that when organisations anthropomorphise AI, giving agents names, listing them on org charts, framing them as teammates, personal accountability fell by nine percentage points among managers, error detection dropped by eighteen percent, and escalation requests increased by forty four percent. These are significant, measurable harms, and the researchers are right to name them.

The Full Context Product model is not a rebuttal to that research. It is an answer to the underlying problem the research exposes. The issue the study identifies is not that AI is being used at scale in workflows. The issue is that when the framing shifts accountability away from the named human, the human disengages. They review less carefully, escalate more readily, and lose confidence in their own judgement. That accountability diffusion is what damages quality. The framing is the cause, not the capability.

The Full Context Product does not humanise the agent. There is no name, no title, no reporting line, no org chart entry. The agent holds context and surfaces it. Every decision belongs to a human. Every output is owned by a named human. The compliance context, the cyber context, the testing context, and the behavioural contracts are all mechanisms by which that accountability is made legible and specific rather than diffuse and assumed. A developer picking up a product under this model knows exactly what they are accountable for, because the context tells them. There is no Scout on the team. There is no Kevin to blame.

The more interesting accountability challenge involves platforms you did not build. When your onboarding system runs on a vendor platform, a low code tool, or a SaaS product, you are operating a channel of execution whose internal development you have no sight of. You are fully accountable for what it does to your customers regardless of that opacity. The context infrastructure of the Full Context Product addresses this directly: the compliance context, the cyber context, the testing context, and the behavioural contracts exist precisely to maintain accountability over systems whose internals are not yours. You cannot control how Salesforce was engineered, but you can define and enforce what acceptable behaviour looks like at the boundary you own. That is where your accountability lives, and that is what the context infrastructure is designed to protect.

6. Testing as a Contract, Not a Check

The testing context deserves more space, because it represents the sharpest conceptual departure from how most organisations currently operate. Most teams treat tests as a safety net: write some tests, run them before release, catch regressions. The test suite grows organically and reflects whatever the developer who wrote it happened to think was important at the time. Coverage gaps are filled in after incidents, which means the suite documents failure history rather than product intent.

The Full Context Product inverts this. Tests are the contract. They are not a check that something works. They are a statement of intent: this is what this product means. This behaviour, in this context, with this input, is deliberate. It was thought about. It was decided. It is not to be changed without an explicit decision to change it, and if it changes without that decision then the build knows something has gone wrong.

Subtle behaviour matters enormously in complex products. An onboarding flow that behaves differently for a high risk customer profile. A payment screen that surfaces a specific warning under particular conditions. A notification that fires only when a particular combination of state exists. These behaviours are often invisible until they break. They break silently when someone changes something nearby without knowing the downstream effect. They are almost never caught in review because nobody reviewing the change knew the behaviour was there in the first place.

Contract those behaviours in as tests, and they become visible. They become named. Any change that touches them triggers a conversation: this is deliberate behaviour, are you changing it intentionally? If yes, update the contract, and that update requires a human decision, not an automated approval. If no, you have just caught a bug that would never have surfaced in any other way.

7. What This Does to Staffing

The organisational implication is significant, and it challenges assumptions that have structured technology teams for decades. We do not need to build a team per product or capability. We need pools of skills organised around domains, with those pools capable of bursting capacity into areas of high client or business need and pulling back when demand normalises.

A security incident does not care that all your security engineers are allocated to a product team working on an unrelated release. A regulatory change does not wait for your compliance people to finish their current sprint. The Full Context model gives the organisation the ability to respond to actual demand rather than being held hostage by allocation commitments made months ago when nobody knew what would actually happen.

The difference in operating posture is stark. In the old model, headcount scales with product portfolio. Every new product or capability creates a gravitational field that pulls in permanent staff to hold it together. In the Full Context model, headcount scales with domain complexity. The number of identity and access specialists you need is determined by the breadth and depth of the access management domain, not by how many products touch that domain. Those specialists burst into products as needed, equipped by the context infrastructure to work effectively without becoming permanent fixtures.

8. The Layers We Hired to Hold Things Together

I want to name what we are actually talking about eliminating, because organisations resist this conversation when it is kept abstract. The twenty person team around the low code onboarding system is not twenty engineers. It is probably four engineers, two of whom actually understand the system deeply. A product owner who spends most of their time in meetings explaining why things are the way they are. A business analyst who translates between the engineers and the stakeholders because neither side trusts the other to speak plainly. A project manager whose primary role is to track whether the four engineers are going to finish before the next change request arrives. A QA team running manual regression tests because the automated test coverage is inadequate and nobody has the authority or appetite to fix it. A support tier whose job is to absorb the breaks that happen twice a week. A vendor relationship manager because the system runs on a platform where the relationship is the only mechanism by which institutional knowledge gets transferred to the people who built it.

Every one of these roles exists because context is not held systematically. The BA exists because the engineers do not have enough shared context to have the product conversation directly with the business. The support tier exists because the testing context is not adequate to prevent the breaks. The vendor manager exists because there is no other way to maintain continuity of understanding with the external supplier. None of this is necessary or beneficial when the context infrastructure is in place. It is just the cost of building teams to hold context that should have been contracted into the system from the start.

9. Superficial Knowledge Is Enough, On Purpose

One of the stranger claims in this model, and one that will draw the most pushback from people who have spent careers becoming deeply expert in specific products, is this: in the Full Context Product, superficial knowledge of the product should be enough to work on it effectively.

This sounds like a reduction in quality. It is the opposite. Deep personal knowledge of a specific system is a coping mechanism for inadequate context infrastructure. When the system does not tell you what it is, you learn it the hard way over years. When the tests do not tell you what behaviour is deliberate, you ask someone who was there when it was built. When the compliance requirements are not surfaced automatically, you rely on whoever happens to hold them in memory. The deep product knowledge looks like expertise, but it is mostly compensating for absent documentation and absent tooling.

A developer with superficial knowledge of a product, working inside a Full Context Product environment, should be able to make a well bounded change safely. They should not need to know the history. They should not need two weeks of shadowing. They pick up the context from the system, understand what the intent is, see the tests that contract the deliberate behaviours, make their change, and do it with confidence because the system will tell them if they have disturbed something they were not supposed to touch.

Deep expertise still matters enormously. But it belongs in the domain, not in the product. The engineer who is deeply expert in identity and access management brings that depth everywhere they work, because the context infrastructure of each product they touch translates their expertise into effective action without requiring them to become a product specialist as a precondition of being useful.

10. The People Inside the Model

The staffing argument is straightforward to make in the abstract and considerably harder to make to the people currently inside those product teams. Leadership owes them a more honest conversation than the model alone provides.

The twenty people around the low code onboarding system did not create the problem this model solves. They filled a gap that the organisation never thought to close any other way. Many of them are skilled, adaptable, and entirely capable of working differently if given the space, the support, and enough time to find their footing in a changed environment. The domain pool model is not a degradation of their contribution. For many of them it is a more interesting way to work. Being locked to a single system that changes twice a year is not a fulfilling professional trajectory for most people who went into technology because they wanted to solve problems.

The transition requires active leadership, not passive announcement. It means being specific about what the new model asks of people: broader domain knowledge, comfort with context switching, the ability to work effectively inside an agentic environment rather than around it. It means investment in the capability building that closes those gaps, and realistic timelines that allow people to develop rather than simply declaring the new model live and watching who keeps up. It means leaders who are present enough in the transition to notice when someone is struggling and respond before the situation becomes irreversible.

It also means being honest that this is a genuine shift in what the organisation needs, and that not everyone will find the new shape of the work suits them. Some people have built careers around deep product ownership and find real meaning in that continuity and depth of relationship with a single system. That is a legitimate way to work, and the organisation should be honest about where it fits in the new model rather than managing the conversation with soft language that avoids the point. The goal is to give everyone a genuine opportunity to thrive in the changed environment. What people do with that opportunity is, in the end, their own decision, and a good organisation respects that while being clear about what it is offering.

11. When the Context Itself Goes Wrong

The model has a failure mode worth naming plainly, because the argument so far has made the context infrastructure sound more self-sustaining than it is. Context decays. Compliance rules change and the compliance context is not updated. A new threat category emerges and the cyber context does not reflect it. A deliberate behaviour is changed without updating the test contract, and the contract starts describing a product that no longer exists. The context infrastructure is only as good as the discipline applied to maintaining it, and discipline without ownership is aspiration.

This is not a reason to reject the model. It is a reason to design the maintenance of context as explicitly as the context itself. In practice this means that the domain specialists who burst into products carry responsibility for the health of the context they use, not just for the change they are making. A security specialist working on a product is not just making a change. They are validating that the cyber context still accurately describes the product’s threat posture and updating it where it does not. A compliance specialist is not just checking a rule. They are ensuring the compliance context reflects the current regulatory position. The context is a living document maintained by the people who work inside it, not a static artefact produced at onboarding and left to drift.

The agentic layer can assist with this actively. It can flag when changes appear to be in tension with the existing context, surface when context definitions have not been reviewed within expected timeframes, and prompt the human working on the product to confirm whether the context still holds. But the judgement about whether the context is correct belongs to the human. The agent surfaces the question. The human answers it.

12. The Real Cost of the Teams We Built

The real cost of the teams we built to hold things together is not the salary bill, though that is real and it compounds. The real cost is organisational calcification. Products become immovable once a team forms around them. They attract headcount. That headcount develops interests in the continuity of the product. The product becomes a constituency, and constituencies resist change. Changing a product, replacing it, or absorbing it into something better requires navigating the organisational territory that has formed around it, and the people in that territory are not being obstructive out of malice. They are protecting their context, the only place it lives.

The Full Context Product breaks this pattern at the root. When the memory of the product lives in the system, and when any competent person with domain knowledge can pick up that context and work effectively, the product is no longer held hostage to the team that formed around it. It can be changed. It can be replaced. It can be absorbed into something else. The context travels with it.

The transition is not simple. It requires discipline in how context is captured and maintained from the moment a product enters the organisation. It requires investment in the agentic infrastructure that holds and surfaces that context over time. It requires a different and more honest conversation with staff about what expertise means and where it lives. And it requires organisational courage to stop hiring coordination layers on top of inadequate context infrastructure and instead fix the infrastructure.

But the direction is clear. The teams we built to hold things together are a symptom of a problem we now have the tools to solve. The Full Context Product is what solving it looks like.

References

Kropp, M., Bedard, J., Wiles, E., Hsu, M., and Krayer, L. (2026). Research: Why You Shouldn’t Treat AI Agents Like Employees. Harvard Business Review. https://hbr.org/2026/05/research-why-you-shouldnt-treat-ai-agents-like-employees

Baker, A. (2025). The Dark Factory. andrewbaker.ninja. https://andrewbaker.ninja