From persistent team context to autonomous teammates: building an engineering organization that learns, prepares, and improves around the clock.
Imagine arriving at work on Monday morning.
Nobody on your team worked over the weekend. Nobody was expected to check Slack, review pull requests, or think about tomorrow’s priorities.
Yet something happened.
An agent investigated the recurring performance degradation that appeared in Friday’s telemetry. Another analyzed a dependency upgrade, reproduced a compatibility issue, and prepared a solution. A third studied the team’s recent delivery patterns and identified a recurring bottleneck.
An operational agent noticed an unusual increase in errors on Saturday, correlated it with a recent configuration change, and collected enough evidence for the on-call engineer to make a decision quickly. It did not take an unauthorized production action.
And a coordinating agent brought everything together.
When the team arrives, it receives a concise briefing:
- What changed, and what matters?
- What has been completed and independently verified?
- Which opportunities are now worth pursuing?
- What needs a human decision?
- Where can the team make the greatest progress today?
The team doesn’t return to a larger pile of work. It returns to a better starting position.
That is the future I want to explore.
Not an engineering team that works 24 hours a day.
An engineering team whose ability to make progress and improve itself no longer depends entirely on humans being present.
1. The Team Has a Memory. Or Does It?
In Hierarchical Context: An Architecture for the AI-Native Enterprise, I proposed organizing engineering context through a hierarchy:
Enterprise → Organization → Team → Service
Each layer provides the context required to understand responsibilities, constraints, decisions, and implementation.
The Team Hub is particularly interesting.
Consider how a personal AI agent becomes more helpful when it remembers someone’s history.
It knows their preferences, ongoing goals, previous decisions, recurring challenges, and the things they have learned. It can distinguish a new question from a continuation of an old conversation.
Without that memory, every interaction begins from scratch.
An engineering team faces a similar problem.
A team has its own history, operating principles, commitments, technical preferences, unresolved disagreements, strengths, weaknesses, and aspirations.
Some of this knowledge lives in documentation. Some lives in Git. Some in issue trackers, telemetry, and incident reports.
Much of it exists only in people’s heads.
And much of the useful context disappears when someone changes teams or a conversation is forgotten.
A Team Hub offers the opportunity to change that.
But there is a difference between documenting a team’s context and making it operational.
What if the Team Hub became the persistent organizational identity and memory that autonomous agents use to act on the team’s behalf?
The distinction matters.
The hub is the durable, governed source of context that different agents can consult, contribute to, and operate within, rather than an agent itself.
It records what the team knows, what it is trying to accomplish, how decisions are made, and where its authority begins and ends.
And because it persists beyond individual sessions, it creates continuity.
A new agent does not need to rediscover everything its predecessor learned.
A returning engineer does not need to reconstruct what happened overnight.
The team’s knowledge becomes reusable infrastructure.
2. The First Autonomous Teammate
Today, many interactions with AI still begin with a person asking for something.
Explain this code.
Investigate this incident.
Implement this feature.
Review this pull request.
The agent performs the requested work. It might operate autonomously for several minutes or hours, but the underlying relationship remains largely reactive.
What changes when the agent becomes a persistent participant in the team’s workflow?
Imagine introducing one autonomous teammate with access to carefully scoped team context and tools.
It understands the team’s goals, services, backlog, engineering standards, and previous decisions.
It can observe new events, investigate opportunities, prepare artifacts, and recommend actions without waiting for a new prompt.
It might notice that a flaky test has disrupted multiple pull requests and prepare a targeted fix.
It might discover that a planned feature conflicts with a newly accepted architectural decision.
It might correlate several recurring incidents and propose a deeper investigation into their common cause.
It might recognize that an important migration has stalled because of a dependency another team has already resolved.
None of these requires the agent to be told exactly what to do at that moment.
It requires the agent to understand what matters to the team.
That understanding cannot come only from a repository or an isolated issue description.
It comes from team context.
The Team Hub now has a second purpose.
It is not only a source of knowledge. It becomes the foundation for autonomous initiative.
This is where I would draw the line between a useful AI tool and an autonomous teammate.
A tool waits for work.
A teammate, within defined responsibilities, can recognize that useful work needs attention.
And importantly, recognizing an opportunity is not the same as having permission to act on it.
3. From One Agent to Many
One autonomous teammate is useful.
But it also quickly encounters limitations.
It cannot investigate every incident, implement every improvement, evaluate every opportunity, and coordinate every dependency simultaneously.
The natural next step is multiple agents, each with different responsibilities and capabilities.
Imagine a team with several specialized autonomous participants:
| Agent | Responsibility |
|---|---|
| Delivery | Implementing approved tasks, tests, and technical improvements |
| Reliability | Investigating operational signals, incidents, and recurring failure modes |
| Quality | Discovering coverage gaps, analyzing defects, and validating changes |
| Discovery | Exploring technical opportunities and evaluating alternative approaches |
| Coordination | Managing dependencies, reconciling findings, and preparing human decisions |
| Learning | Identifying patterns in outcomes and proposing improvements to team practices |
These are logical responsibilities, not necessarily six permanently running processes. Depending on workload, several can share one runtime or be instantiated only when needed.
The agents share an understanding of the team’s objectives while operating with distinct permissions.
An investigation agent may identify a problem that deserves implementation. A delivery agent may prepare the fix. A quality agent may independently challenge the result.
A coordinating agent ensures that this activity doesn’t become a collection of disconnected accomplishments.
This produces a new coordination problem.
If agents operate independently, they may duplicate investigations, create conflicting changes, compete for the same resources, or optimize different objectives.
At that point, adding more agents can reduce overall efficiency.
We have seen the human version of this problem for decades.
More contributors do not automatically produce more progress.
The solution is shared context, clear ownership, explicit contracts, and a way to coordinate work, rather than unlimited agent autonomy.
This is where the Team Hub becomes more valuable.
It can serve as a shared point of reference for:
- Objectives, priorities, and success criteria.
- Current work, ownership, dependencies, and active constraints.
- Agent capabilities, identities, permissions, and budgets.
- Decisions, evidence, and unresolved questions.
- Relevant history and lessons from previous attempts.
- The team’s current operational state.
The hub is the durable context layer. Live task coordination, locks, execution status, and event streams can remain in purpose-built systems connected to it.
In other words, we do not need to turn Git into a distributed scheduler.
We need to connect the team’s memory with the mechanisms through which work gets done.
4. The Team’s Optimization Loop
This leads to the central idea of the article.
What if optimizing the team’s performance became a continuous activity rather than an occasional management exercise?
Engineering managers already perform this work.
We look at delivery progress, incidents, quality, dependencies, capacity, and organizational friction.
We ask why something took longer than expected. We identify an inefficiency. We experiment with a different process. We check whether it helped.
But the cycle is often relatively slow.
An observation on Monday might become a discussion on Wednesday, an improvement task next week, and a measured result several weeks later.
Not because the team lacks ambition, but because everyone is busy with delivery.
With persistent context and autonomous agents, some parts of this optimization cycle could run much more frequently.
I imagine a continuous loop:
- 01 · ObserveCollect meaningful signals from the systems surrounding the team.Guided by the outcomes the team actually cares about.
- 02 · UnderstandConnect signals to their context. Form hypotheses, investigate evidence, and preserve uncertainty.
- 03 · PrioritizeIdentify what would make the greatest difference given current goals, risks, available capacity, and dependencies.Doing nothing is a valid recommendation.
- 04 · ActFor low-risk, explicitly authorized activities, agents can execute.For consequential decisions, agents prepare evidence and request human judgment.
- 05 · VerifyEvaluate the result against observable criteria, preferably through independent checks.
- 06 · LearnSuccessful approaches become reusable patterns. Failed experiments become evidence.
Team HubEvolves with approved changes and provenance, and the next cycle starts from Observe.
Observe
Collect meaningful signals from the systems surrounding the team.
Delivery progress, build failures, production incidents, customer feedback, operational cost, review delays, unresolved dependencies, and recent changes.
But not simply because we can collect them.
Observation should be guided by the outcomes the team actually cares about.
Understand
Connect signals to their context.
A slow deployment is not necessarily a deployment-system problem.
It could be a test architecture problem, a risky dependency, insufficient ownership, or a quality gate doing precisely what it should.
The agent should form hypotheses, investigate evidence, and preserve uncertainty rather than immediately declaring a root cause.
Prioritize
This is perhaps the most important stage.
The goal is not to find everything that could be improved.
An engineering team will never run out of potential improvements.
The goal is to identify what would make the greatest difference given current goals, risks, available capacity, and dependencies.
An agent should be able to recommend doing nothing when no worthwhile intervention is justified.
Act
For low-risk, explicitly authorized activities, agents can execute.
They can investigate, run experiments, generate tests, prepare changes, or update verified documentation.
For consequential decisions, they prepare evidence and request human judgment.
Verify
An agent saying it completed a task is not verification.
The result must be evaluated against observable criteria, preferably through independent checks.
Did the fix resolve the problem?
Did it introduce regressions?
Was the proposed performance improvement actually measured?
Was the hypothesis wrong?
Learn
Finally, the outcome should improve future work.
Successful approaches become reusable patterns.
Failed experiments become evidence.
Recurring problems become candidates for systemic improvement.
Outdated assumptions are challenged.
The Team Hub evolves, with approved changes and provenance, as the team learns.
The important outcome is not simply that agents complete more work.
The system should become better at deciding what work is worth doing, how to do it, and how to know whether it helped.
That is a much more ambitious definition of continuous improvement.
5. From Working Hours to Continuous Progress
Humans need rest.
We have families, interests, responsibilities, and lives beyond engineering.
Our working day has a natural boundary. A useful engineering system should respect it.
Autonomous agents do not have the same constraint.
An agent can continue investigating a problem after everyone has left. A long-running experiment can complete overnight. A validation pipeline can evaluate several candidate approaches over the weekend.
This opens the possibility of separating two kinds of time.
| Human collaboration time | Autonomous execution time | |
|---|---|---|
| Who | People provide judgment, creativity, accountability, and shared understanding | Authorized agents make progress on work that does not require immediate human involvement |
| When | During the day | During the night |
| What happens | The team clarifies objectives, makes decisions, resolves ambiguity, and chooses worthwhile work | Agents investigate, execute, test, compare alternatives, and prepare the next set of decisions |
These periods can reinforce one another.
When people return, they are not forced to resume every task from the point where they left it.
Some uncertainty has been removed.
Some options have been evaluated.
Some work is ready for review.
And ideally, some problems have been prevented.
A useful way to think about this is through latency.
Many engineering tasks contain long periods during which the next meaningful action is waiting for someone’s attention.
A test fails late in the evening. A dependency becomes unblocked after the responsible engineer leaves. An investigation could proceed, but nobody is available to continue it.
Autonomous execution can reduce that waiting time.
However, there is a subtle trap.
If a team returns each morning to 40 new pull requests requiring careful review, we may have moved the bottleneck rather than improved performance.
In The Maximum Velocity of a Team, I argued that sustainable velocity is constrained by much more than production capacity.
Judgment, verification, integration, and adoption matter.
The same principle applies here.
Twenty-four-hour execution is valuable only when it improves the team’s end-to-end progress.
The objective is not maximum overnight output. It is maximum useful readiness for the next human working session.
6. The Morning Should Begin With the Best Decisions
Consider two possible outcomes of an overnight autonomous system.
| The first outcome | The second outcome | |
|---|---|---|
| Engineers arrive to | Twelve pull requests, eight new issue tickets, and a long report explaining everything the agents attempted | A short, carefully prepared briefing |
| The agents | Were productive | Prepared decisions |
| The humans | Are overwhelmed | Know where to spend their attention |
The second briefing contains:
- One issue already resolved through an authorized, verified change.
- Two candidate fixes evaluated, with evidence supporting one.
- A potential production risk, investigated and ranked.
- Three lower-value tasks, deliberately deferred.
- One architectural decision that deserves the team’s attention.
The second outcome is far more interesting to me.
Not because less work happened, but because the system made better use of human attention.
I would want a daily briefing with five questions:
| Question | What the answer contains |
|---|---|
| What deserves our attention? | A ranked set of opportunities and risks, connected to team objectives and backed by evidence |
| What is already accomplished? | Verified results, separated from claims that remain uncertain |
| What decisions do we need to make? | Explicit tradeoffs, recommended options, and the consequences of choosing differently |
| What should we avoid spending time on? | Duplicate work, low-value opportunities, disproven hypotheses, and items that no longer deserve priority |
| What did the system learn? | Patterns, limitations, and proposed improvements to the team’s operating practices |
There is a critical distinction between presenting information and preparing decisions.
A dashboard reports what happened.
A useful autonomous teammate helps the team understand what to do next and why.
Humans remain accountable for consequential decisions, but they receive better-prepared choices.
7. The Weekend and the On-Call Boundary
Weekends make the opportunity particularly visible.
Imagine a Friday afternoon when the team finishes its work and goes home.
Several experiments are running. There are a few unresolved performance questions. A dependency upgrade is pending validation.
Those activities need not stop simply because the weekend begins.
Agents could continue bounded investigations, run experiments, validate candidate changes, and assemble evidence.
Monday morning becomes a continuation of useful progress rather than a restart.
Operational support introduces another dimension.
Engineering teams already have on-call rotations because production systems do not observe office hours.
But being on call is expensive in human attention.
An alert requires someone to interpret signals, inspect dashboards, correlate events, understand recent changes, and determine whether intervention is necessary.
Much of that investigation can potentially be automated.
An operational agent could:
- Correlate an alert with recent deployments, configuration changes, and historical incidents.
- Inspect metrics, logs, traces, and relevant runbooks.
- Evaluate possible explanations and collect supporting evidence.
- Execute narrowly authorized, reversible remediation when conditions are verifiably satisfied.
- Escalate when an action exceeds its authority, evidence is inadequate, or risk is too high.
The result might be a resolved low-risk issue, a more informative escalation, or simply the elimination of a false alarm.
But I would be careful with the concept of an autonomous on-call engineer.
Production responsibility is not just a technical capability.
It involves authority, business consequences, security boundaries, and accountability.
An agent should not independently decide that customer data can be modified, a risky deployment can proceed, or a complicated incident deserves no human attention.
Autonomy needs to be earned, not assumed.
A natural progression is:
Observe → Diagnose → Recommend → Execute bounded actions → Expand authority based on demonstrated reliability
Each stage requires evidence, safeguards, and clearly defined escalation behavior.
The goal is to let humans rest more confidently, not to hide production risks behind a model’s confidence score.
8. What Prevents Continuous Optimization From Becoming Continuous Noise?
There is an obvious failure mode in everything I have described.
Once agents can discover work themselves, they can also manufacture an endless supply of work.
Another refactoring opportunity.
Another test improvement.
Another architectural simplification.
Another generated ticket.
Another investigation that produces five more investigations.
The system becomes spectacularly busy without becoming meaningfully better.
This risk grows as the number of autonomous agents increases.
Therefore, continuous optimization needs constraints that are just as important as the agents themselves.
- An approved objective. Every autonomous initiative needs a relationship to an approved objective or an explicit operational responsibility.
- Opportunity cost. The system must understand it. Pursuing one improvement means consuming compute, review capacity, and possibly human attention that could be used elsewhere.
- Exploration versus commitment. There must be a distinction between the two. Agents should be free to identify possibilities within their permissions, but not free to turn every possibility into a new team obligation.
- Verification and permissions. Independent verification and enforceable permissions are essential. A prompt describing what an agent should not do is not a sufficient security boundary.
- A review-capacity budget. An agent system that creates more review work than people can responsibly absorb is not necessarily improving throughput.
And finally, the optimization process itself needs feedback.
Are agent proposals useful?
Are humans accepting them?
Are accepted changes generating real value?
Which recommendations were wrong?
Which autonomous tasks required substantial rework?
Are agents helping the team understand its systems better, or gradually making them more difficult for humans to reason about?
A system that continuously improves code but deteriorates human understanding may eventually make the organization less resilient.
That would be a poor optimization.
9. The Team Hub as a Living Profile
This brings the argument back to the Team Hub.
A personal agent becomes more useful when it can maintain an accurate understanding of the person it supports.
In a similar way, the Team Hub can evolve into a living profile of an engineering team.
But I would divide this profile into several distinct layers.
| Layer | What it represents |
|---|---|
| Identity | Mission, responsibilities, service ownership, operating principles |
| Memory | Decisions, historical incidents, lessons, successful and failed experiments |
| Current state | Objectives, active work, risks, dependencies, operational health |
| Capabilities | Human responsibilities, agent roles, tools, permissions, and constraints |
| Learning | Measured outcomes, recurring bottlenecks, and proposed improvements |
The first two give the team continuity.
The third helps agents reason about the present.
The fourth defines what work the combined human-AI team can perform and who is permitted to perform it.
The fifth creates a path toward improvement.
Not every element belongs in the same repository.
Fast-changing execution state belongs in operational systems. Sensitive personnel context should not be turned into an unrestricted team-memory file. Private conversations and unapproved assumptions should not quietly become organizational facts.
The hub should provide governed references, durable records, and authoritative context, with explicit ownership and access rules.
This is an important design choice.
A useful team profile must be trustworthy, not merely comprehensive.
And its memory must be correctable. If an agent repeatedly makes the wrong recommendation because of an outdated assumption, the team should be able to trace, challenge, and replace that assumption.
The objective is not to preserve everything.
It is to preserve the understanding that improves future decisions.
10. A New Responsibility for Engineering Leadership
If this model becomes practical, engineering leadership changes.
Managers will still be accountable for outcomes, people, organizational health, and the sustainable delivery of valuable software.
But they will increasingly need to think about the autonomous capabilities available to their teams.
What can our agents do today?
What are they good at?
Where do they repeatedly fail?
Which work should remain entirely human?
What additional context would make them more effective?
Where is autonomy economically useful?
What types of verification justify expanding their responsibilities?
How do we keep human understanding growing alongside autonomous capability?
These questions resemble the questions leaders already ask about team capacity and effectiveness.
But there is an important difference.
We should not manage autonomous agents as if they were human employees.
An agent does not need career development, belonging, or psychological safety. It needs coherent objectives, appropriate context, verifiable outputs, and enforceable constraints.
People need much more than that.
This is why I would connect continuous autonomous improvement with my earlier thinking in AI-Free Fridays.
I do not want continuous autonomous progress to become an expectation that humans should also be continuously available.
Ideally, it enables the opposite.
If routine investigation, validation, and preparation can happen without consuming human attention, we should be able to protect more time for the things people do best.
Deep thinking.
Shared judgment.
Exploration.
Mentorship.
Creative disagreement.
And the satisfaction of building something meaningful together.
The measure of a successful autonomous team is not whether every available hour is filled with activity.
It is whether the team produces better outcomes with less unnecessary human effort and more space for human growth.
11. How I Would Start
I would resist beginning with a fully autonomous team of agents.
The architecture is attractive, but there are too many unknowns to justify adopting the entire vision at once.
Instead, I would start with one team, one hub, and one carefully bounded autonomous workflow.
| Stage | What it adds | Boundary or check |
|---|---|---|
| 1. A trusted team profile | A Team Hub containing the team’s objectives, ownership, operating practices, important decisions, and links to authoritative service context | Useful to humans before agents are expected to rely on it |
| 2. A daily observer | An agent that reads approved operational signals and prepares a daily summary of meaningful changes | Initially cannot modify source code, production systems, or team commitments. Measure whether its observations help the team make better decisions |
| 3. An autonomous investigator | The agent selects from approved categories of investigation, such as flaky tests, recurring build failures, and performance regressions, executes bounded experiments, and proposes changes in isolation | Must report evidence, uncertainty, cost, and recommended next steps |
| 4. Multiple cooperating agents | Investigation, implementation, and verification, separated where that adds measurable value | Coordination prevents duplicated work, conflicting changes, and unbounded activity. The handoff to humans stays concise |
| 5. A continuous improvement loop | Accepted and rejected recommendations, verified outcomes, and recurring patterns improve future prioritization. Changes to the Team Hub and agent operating procedures go through reviewable processes | Track whether the combined system is actually improving |
The success criteria should be practical:
- Less time spent reconstructing context.
- Faster resolution of recurring problems.
- Better prioritization of valuable work.
- Fewer avoidable interruptions.
- Reduced waiting time between meaningful workflow stages.
- Less rework and fewer regressions.
- Sustainable improvements without increasing human workload.
I would explicitly measure the cost of achieving those results, including compute, tooling, coordination, and human review.
A system that spends more resources than the value it creates may be impressive but not useful.
And if autonomous overnight work produces no meaningful benefit for a particular team, there is no reason to force it.
The architecture should create options, not obligations.
12. The Team as a Continuously Learning System
I started with a simple analogy.
A personal agent becomes more effective when it understands the person it serves.
A team can benefit from the same continuity.
The Team Hub provides persistent context. Autonomous agents use that context to investigate, execute, coordinate, and learn. Feedback from the real world changes what the team knows and how future work is approached.
What begins as a repository of organizational knowledge can become the foundation of a continuously learning engineering system.
The progression is meaningful:
A team that documents what it knows.
A team whose agents understand what it knows.
A team whose agents can act on that understanding.
A team whose agents coordinate with one another.
A team whose combined human and autonomous capabilities improve over time.
I do not think the ultimate goal is a company in which every minute produces another commit, issue, or report.
The interesting future is one in which the team is better prepared whenever people choose to engage.
The overnight investigation that eliminates an hour of uncertainty.
The weekend experiment that reveals an architectural opportunity.
The operational agent that reduces an unnecessary interruption.
The Monday briefing that gives everyone clarity about what really matters.
And the accumulated memory that helps the next investigation succeed where the previous one failed.
We often describe AI’s potential in engineering as doing more work with fewer resources.
That is part of the story.
But the more interesting possibility is that we can build organizations that are continuously learning how to work better.
People should not have to work around the clock for their team to keep getting better.