Who works here now, and how do we design that?
The previous sections of Stage 5 made the case for the human work. What humans bring. What the workforce experiences during the transition. The cognitive posture that distinguishes development from unexamined dependence. The conditions that support up-leveling. The hidden capability AI may help surface. What has to be unlearned. The role of challenge in worthwhile work.
What this part has not yet addressed is the operational expression of all of that. The org chart. The roles. The hiring rubric. The pipeline. What the workforce of an AI-Native company might look like two or three years from now, after some of the human work has begun and some of the architecture is in place. Neither is ever finished. All of it is design work. Your leadership team is doing it whether it recognizes that or not, because every hire, promotion, layoff, automation, and reorganization builds the workforce by default if not by design.
The org chart is changing in two directions at once. The human side is changing through role types, management layers, learning pipelines, and the skills for which the company hires. The agentic side is emerging as software takes more active roles in workflows and therefore needs identities, permissions, evaluation, and accountable human ownership. The two shifts interact. A leadership team that treats workforce design and system delegation as one connected question can produce a more coherent operating model than a team that lets each proceed in isolation.
The Human Side: New Role Types
The first human-side shift is in the role types themselves. In a 2026 Lightcone conversation, Y Combinator partner Diana Hu described three archetypes for companies built around AI and connected the framing to Jack Dorsey's thinking at Block. The accounts are not identical. Dorsey's published model names IC, DRI, and player-coach. Hu's discussion uses the phrase AI-founder type for a hands-on leader who demonstrates what the new tools make possible. The three categories below are therefore a synthesis for this field guide. They are my reading of Block's structure, and the categories remain open to revision.
The IC is the individual contributor who does the work. Writes the code. Builds the model. Drafts the analysis. In many AI-Native roles, the IC will be expected to use approved AI where it improves the work, with the human contribution including domain skill, judgment, taste, verification, relationships, and accountability. AI should not be the default in work where law, confidentiality, safety, client agreement, or the need to maintain unaided capability says otherwise. Fluency is becoming a baseline in some roles and remains specialized in others.
A DRI, the Directly Responsible Individual, owns a defined outcome and has authority to make the calls inside it. Accountability without authority is theater; authority without checks is risk. The role can become more useful when work crosses functions or management layers change because it makes one human responsible for integration without pretending that legal, fiduciary, professional, or executive accountability can be delegated away.
AI-Founder is Hu's useful name for a posture more than a standard job title: a leader who works hands-on enough to demonstrate what AI changes, connects architecture to the operating model, and takes responsibility for where the system should and should not act. The posture cannot replace the engineers, security specialists, domain experts, workers, and risk owners who make the system real. In a startup, a founder may carry it. In a larger company, the work may be distributed across product, technology, operations, legal, security, data, and workforce leadership. Where one executive owns the integration, the reporting line matters less than the authority and cross-functional accountability.
These three archetypes are a starting frame, and others will emerge. Dorsey's player-coach belongs beside them because developing human craft is not optional. So do roles for assurance, data stewardship, security, employee representation, and domain accountability. The point is not that every company needs these titles. It is that existing roles should be decomposed against the work now required rather than renamed around a fashionable taxonomy.
The Human Side: Compressing Management Layers
A second possible shift is structural. Some companies are compressing management layers between the CEO and the individual contributor; others are adding governance, platform, and risk roles around AI. There is no evidence that hierarchy is compressing directionally everywhere. The design question is which layer exercises necessary judgment, development, coordination, or control and which exists mainly because information used to move slowly.
Block announced in a February 2026 SEC filing that it expected to reduce its workforce by more than forty percent. The filing described the plan as aligning organizational structure with its operating model and strategic priorities; it did not say the reductions concentrated in middle management. In a later Sequoia conversation, Jack Dorsey said Block's maximum depth was about five people between him and another individual and that he wanted to reduce it to two or three. He presented an AI intelligence layer as a way to provide shared context and reduce information-routing work. That is an executive thesis being implemented after a severe restructuring, and whether the model works remains to be seen.
Block makes visible a hypothesis many companies are considering: if software can make status, dependencies, and context more accessible, some information-routing work can shrink. AI does not resolve conflict, allocate scarce resources legitimately, notice every hidden dependency, or guarantee that the shared context is true. Managers also do more than route information. They develop people, translate strategy, protect teams, exercise judgment, and carry formal responsibilities. Companies should evaluate the work of each layer before cutting a category. If they remove coordinators and mentors indiscriminately, they may discover that the supposedly redundant layer was holding integration, apprenticeship, and trust together.
Layer redesign strengthens the case for senior IC roles with substantial scope and no people-management obligation. Dual career ladders predate generative AI, but AI makes the old promotion bargain look even stranger: the company should not remove an excellent practitioner from the work merely to increase status and pay. A deliberately designed IC track can improve retention and craft leadership. Whether it does depends on compensation, authority, recognition, and mobility matching the management track in practice rather than only on paper.
The Pipeline Question: How Seniors Get Formed
A third shift may be the most uncomfortable. Parts of the pipeline that formed senior workers are changing, and the AI-Native company has to decide how senior judgment will be formed when entry-level tasks change.
The pre-AI pipeline ran partly through entry-level work. Junior analysts assembled analyses, associates reviewed documents, and developers wrote boilerplate. AI can now perform portions of each task, with uneven reliability. Some of the work was needless toil. Some exposed novices to cases, exceptions, causal chains, and feedback that later informed judgment. Repetition alone did not create expertise, and many old pipelines excluded capable people or taught bad habits. The design mistake is to automate a task without identifying which learning it carried and how that learning will be rebuilt.
I call this the apprenticeship inversion: the technology can perform work assigned to novices by drawing on patterns created by experts, while the organization still needs a way for novices to become those experts. I have not found a reliable published source for the earlier attribution of this phrase to Steve Akkara, so the idea stands here as this book's label, carrying only the weight of its own argument. The risk is real but the outcome is not predetermined. Junior hiring expectations are mixed, task exposure is changing unevenly, and new forms of practice may prove better than the old ones. What leaders cannot assume is that senior talent will replenish itself after its formative work disappears.
Companies taking the risk seriously are experimenting with a different pipeline. Juniors can learn to frame tasks for AI, evaluate output, trace evidence, integrate across tools, and recognize failure. They also need direct encounters with source material, customers, operations, consequences, and the underlying task without assistance. Orchestration may become formative; it has not yet accumulated the decades of evidence the old paths have. Mentors need enough practice to teach both the tool and the domain, and they need protected time to observe work rather than merely inspect polished output. Organizations should test whether novices are gaining independent capability instead of assuming a stage label guarantees it.
There is survey evidence pointing in more than one direction on the pipeline question. The hiring expectations in Section 5.7 leave the apprenticeship question open: what work will give new employees the experience they need? The survey did not ask whether a lower entry barrier caused those expectations, and expectations are not labor-market outcomes. It is evidence that the question is still open.
Agents as a Workforce Category
The org-chart shifts on the human side are real and they are also incomplete. The other thing happening to the org chart is that a new category of entity is appearing on it. Agents.
The framing is recent and contested. AI agents are software systems. In the legal, moral, and experiential senses of the word, workers are people. Yet treating them as ordinary undifferentiated software can hide the delegation involved when a system selects tools, accesses data, and takes consequential actions. “Workforce category” is a management metaphor for making that delegation visible. It can prompt useful questions about identity, scope, ownership, evaluation, and lifecycle. It becomes dangerous when it anthropomorphizes software, erases the humans whose labor built and supervises it, or implies that an agent can bear accountability.
A production agent should operate through an attributable workload or service identity rather than a shared human login. That identity needs narrowly scoped and preferably short-lived credentials, explicit authorization, and records connecting a particular version, configuration, delegation, and action. A named human or accountable function owns the deployment. A supervisor agent may monitor another system, but it cannot absorb human accountability. The deployment has an evaluated performance profile and a controlled lifecycle: approval, release, monitoring, change, suspension, and retirement.
The vocabulary resembles workforce management because both domains ask who may do what, under whose authority, and with what evidence. The differences matter just as much. Software does not consent, develop a career, possess rights, or suffer a bad workplace. A company operating hundreds of agent instances needs a registry, access governance, evaluation, incident response, change control, and accountable human ownership. Calling that an agent workforce can help leaders see the operating problem. It does not turn the systems into employees or make HR practice the right technical control plane.
Intellectual lineage. Three 2026 sources illuminate different pieces of the shift, but they do not establish that agents are employees or independently accountable entities. Muqsit Ashraf's World Economic Forum article argues for AI-native business models oriented toward growth rather than efficiency alone. Cole Stryker's IBM explainer describes agentic workflows as one expression of systems designed around AI from the outset and emphasizes governance and continuous monitoring. Bessemer Venture Partners' Graph AI case study describes one pharmacovigilance product's “push model,” in which the system surfaces information inside a workflow without waiting for a prompt. That is a company-specific design choice, and other operations may reasonably choose differently. Read together, the sources support a narrower conclusion: software is being delegated more active roles in workflows, so scope, controls, and human accountability need to become more explicit.
Ashraf, M. (2026). Why AI's greatest payoff is growth and how leaders can build AI-native businesses to capture it. World Economic Forum. / Stryker, C. (2026). What is AI native? IBM Think. / Bessemer Venture Partners (2026). Graph AI: A service firm turned AI-native solution for pharma and life sciences. BVP Atlas.
Agent Identity, Permissions, and Accountability
The leadership team that decides to treat agents as a workforce category has to make several specific design decisions where the field is just beginning to converge.
Identity. A product name is not a security identity. “Devin,” “Einstein,” or “Copilot” may identify a product family while thousands of instances, versions, and delegations act within it. Each production deployment needs a unique machine-readable identity linked to its owner, configuration, version, environment, and authority. Human-readable names help people talk about the system. Workload identities, credentials, and verifiable records make its actions attributable. NIST opened formal work on software-agent identity and authorization in 2026 precisely because the details are not yet settled.
Permissions. The deployment has a defined scope: what data it can read, which tools it can invoke, what systems it can change, how much it can spend, and which actions require human authorization. Begin with least privilege and separate read, propose, approve, and execute. Performance evidence may support a scope change, but permission expansion should remain an explicit risk decision with expiration and revocation, which a person makes and can undo. Role-based access control may help, alongside attribute-, policy-, and task-specific controls for delegated authority.
Accountability. When an agent contributes to a bad outcome, accountability remains human and institutional. A named service owner should be answerable for operation, but responsibility may also sit with the executive authorizing the use, the process owner, the professionals relying on it, the vendor, and the organization itself. One “manager” cannot become a liability sink for a system they lack authority or resources to control. Map decisions and duties before deployment, including who can stop the system and who must notify affected people.
Audit and observability. Material inputs, tool calls, approvals, outputs, policy decisions, errors, and state changes need tamper-resistant records sufficient to reconstruct consequential actions. “Log everything” is neither feasible nor responsible: secrets, personal data, privileged material, and sensitive prompts require minimization, access control, retention limits, and sometimes deliberate exclusion. Review should be routine and risk-based, happening well before any incident. Observability supports detection and learning; it does not by itself make an unsafe action safe.
None of those four design decisions is exotic, but none is solved merely by naming it. Any company delegating consequential action to software has to settle them. If leadership leaves them implicit, defaults, vendors, and local teams will settle them instead.
The Interface: How Humans and Agents Relate on the Chart
The most operationally interesting question, and one with no settled answer, is how humans relate to agentic systems in the work. Four design patterns are useful to examine. They are an analytical frame for this book, and no one has measured them across AI-Native companies.
The agent is owned by a human-led function. A production deployment has defined scope and a named owner with authority to suspend it. Human review is calibrated to consequence rather than applied ceremonially to every output. The pattern preserves a clear accountability path, but the relationship is not literally managerial and need not scale one human for one agent. One team may govern many narrowly scoped systems if evaluation, controls, sampling, and escalation remain credible.
The agent is monitored by another automated system. A controller can check policy, compare outputs, route exceptions, or monitor a fleet of worker agents. Calling it a senior agent risks confusing hierarchy with assurance. The controller may share models, data, vulnerabilities, or blind spots with the systems it checks. It can reduce human review volume; it cannot decide which matters require human judgment without a human-defined policy, tested escalation behavior, independent controls where needed, and a recovery path when the monitor misses the failure.
The agent appears as a participant in a team workspace. It can draft, retrieve, challenge, summarize, or trigger tools alongside human conversation. “Peer” or “teammate” may be a useful interaction metaphor, but the system has no equal standing, reciprocal obligation, or independent accountability. The interface should make its nonhuman status, capabilities, sources where appropriate, and current authority legible. Humans need practice in using, questioning, correcting, and stopping an active system together.
The agent operates in the background. Software already performs invisible automation, and some agentic work will be embedded in ordinary systems. Invisibility may simplify an interface; it can also defeat informed reliance, contestability, worker consultation, and legal disclosure duties. People should be told when AI materially shapes a consequential recommendation, evaluation, or action affecting them, and they need a path to explanation, correction, and human review. The design question is not whether every internal call gets a badge. It is where invisibility changes a person's rights, choices, expectations, or ability to diagnose failure.
The four patterns are not mutually exclusive. A company may use several within one process. The leadership decision is which pattern fits the task and consequence, what controls surround it, how affected workers participate in the design, and how the system's role is communicated.
What Is Not Yet Settled
Several substantive questions about the org chart of an AI-Native company do not yet have settled answers in the field. The leadership team making decisions today is making them while the conventions are still forming. The honest framing is to name what is not yet settled rather than pretending the field has converged.
One caution about that framing, because it can be read as permission to wait. Products shipped ahead of standards. In February 2026, NIST's National Cybersecurity Center of Excellence released a concept paper on applying identity and authorization practices to software and AI agents, and NIST launched an AI Agent Standards Initiative covering interoperability, security, and identity. Existing workload identities, service principals, short-lived credentials, and policy systems provide building blocks; no evidence says every major identity stack has solved agent delegation. A leadership team should not wait for convergence to prohibit shared human accounts, constrain authority, and preserve attribution.
The legal and HR question. An agent is not an employee under current employment law merely because a company calls it one. The relevant legal questions concern the humans: worker consultation, discrimination, privacy, surveillance, safety, labor rights, intellectual property, professional duties, and accountability for automated decisions. The EU AI Act, GDPR, and employment law regulate systems and their effects in particular contexts; they do not create an employment relationship for software. The workforce metaphor should never obscure who holds rights and who owes duties.
The cost-allocation question. Agents do not receive compensation; vendors, compute providers, integrators, reviewers, and the people whose knowledge supports the system do. Unit inference costs may fall while total cost rises through volume, integration, evaluation, security, energy, compliance, and failure. Human labor costs also move with markets and job design. Economic pressure may favor automation for some tasks, but “more agents and fewer humans” is not a law. Quality, demand, liability, customer preference, regulation, and complementary work shape the result. Leadership is making allocation decisions today whose distributional effects should be explicit.
The evaluation question. An agent does not need the equivalent of a human performance review. It needs system evaluation: task success, error severity, calibration, policy compliance, security, latency, cost, resilience to unusual inputs, escalation quality, and effects on people and the surrounding process. Many deployed agents change through models, prompts, tools, retrieval sources, policies, or configuration rather than retraining. Evaluate before release, monitor in operation, re-evaluate every material change, and compare the combined human-AI process with credible alternatives.
The cultural question. What does it do to a workforce when active software appears as a teammate, evaluator, monitor, or invisible intermediary? People may experience the same system as useful tool, threat, partner, bureaucracy, or surveillance. Design choices, employment consequences, transparency, reliability, and participation are likely to matter. The patterns are too young and context-dependent to support a general outcome claim, which is a reason to involve workers and measure effects rather than infer sentiment from adoption.
Naming what is unsettled is honest and strategically useful. It creates room for reversible experiments, explicit assumptions, worker participation, and stop conditions. Early movers may shape conventions; they may also create expensive failures. Deliberate does not mean first. It means choosing with evidence, recording why, and retaining the ability to change course.
Bring this into the room. Block ninety minutes with your leadership team and workforce representatives and walk through the following exercise. Draw your current org chart on a whiteboard: the actual roles, reporting lines, decision rights, and informal coordination. Now draw a twenty-four-month hypothesis. Be specific. Which tasks remain human-led? Which are AI-assisted? Which may be delegated to an agent under human accountability? Where are professional judgment, security, worker voice, and independent review required? How many management layers, and what necessary work does each perform? Where are the senior IC and player-coach tracks? Who owns cross-functional AI integration? Then name the transitions. Do not write “this role becomes an agent.” Identify the tasks changing, the evidence required, the people affected, the learning pipeline, the consultation and support owed to them, and the stop conditions. The artifact does not predict the future. It surfaces decisions the team might otherwise make implicitly.
The Strategic Case
The strategic argument for designing the workforce deliberately, including human work and delegated software, is that the alternative produces accumulated consequences the company did not intend and may find costly to reverse.
The leadership team that does not design the workforce will still have a workforce two years from now. It will be the result of accumulated individual decisions: who got hired, who got promoted, who left, what work got automated, what agents got deployed. Without a shared design, those decisions can produce recognizable mismatches: too many coordinators and too few senior ICs for the work, agent capabilities that do not fit what people are actually doing, or pipeline gaps discovered only when senior talent is already scarce. A design does not eliminate those errors. It makes the assumptions connecting the decisions visible soon enough to challenge them.
A shared workforce design makes a different outcome more likely. Hiring can align with the operating model. Agent deployments can fit the work rather than merely the vendor roadmap. Apprenticeship can combine orchestration with domain practice and unaided capability. Compensation, recognition, consultation, and career systems can reflect the workforce being built rather than the workforce of ten years ago. The design is a hypothesis that must be revised as performance and human consequences become visible.
Over three to five years, that work can produce a more capable and coherent workforce than uncoordinated automation does. It can also fail through bad forecasts, weak execution, or a strategy that treats people as variables on a chart. The plan gives people a record of which jobs may change, why, and what support the transition will require.
The next section takes these workforce questions into the design of one function, following the work into roles and relationships a team can test.