AI coding agents have changed the way I think about software development.
Not long ago, when I thought about using AI for development, I mostly thought about asking a model a question, getting an answer, copying some code, and then continuing the work myself.
That model is changing quickly.
Today, an AI agent can be given a task, inspect a repository, modify files, run tools, investigate errors, and continue working toward an outcome.
But that creates a new question.
What happens when the AI isn't just an assistant, but becomes part of the team?
If one developer starts an agent on a task, can another developer add context?
Can someone redirect the agent while it is working?
Can another person review the result and continue the task?
Can the work be handed from one person to an agent and back again without losing the context?
These questions are becoming increasingly important as development teams start running multiple AI agents alongside human developers.
The challenge isn't simply getting an AI agent to do work.
It's figuring out how humans and agents can work together without creating another layer of disconnected conversations, prompts, terminals, and status updates.
What Does Human-Agent Collaboration Actually Mean?
I think there is an important distinction between using AI and working with an AI agent.
When I ask ChatGPT to explain an API, that's AI assistance.
When I ask an AI coding tool to suggest a function, that's also assistance.
But an agent can operate differently.
Instead of waiting for me to provide every individual instruction, an agent can receive a broader objective and execute multiple steps toward it.
That changes the workflow.
A developer might create a task such as:
Add authentication to the new API endpoints, update the tests, and make sure existing endpoints continue working.
The agent can then inspect the repository, make changes, run tests, and report what happened.
But the developer doesn't necessarily disappear from the process.
They may realize halfway through that the authentication requirement needs to work differently.
A second developer may notice an edge case.
A reviewer may ask for additional tests.
The product manager may change an acceptance requirement.
The agent needs to respond to those changes.
That's what I mean by human-agent collaboration.
The human isn't simply giving the agent one prompt and waiting for the final answer.
The human and the agent are participating in an ongoing piece of work.
Can Multiple People Join the Same Live AI-Agent Session?
This is one of the most interesting questions around agent-based development.
Imagine that a developer starts an AI agent to work on a feature.
The agent gets halfway through the implementation.
Another developer looks at the task and realizes that the original approach won't work because of a constraint in another part of the system.
In a traditional workflow, that second developer might message the first developer, who then returns to their terminal and tells the agent what to do.
That's a lot of unnecessary handoff.
A better model is to make the task itself the shared context.
Instead of treating the agent session as someone's private conversation, the team can keep the requirement, discussion, execution history, and review connected to the same piece of work.
This is one of the core ideas behind Sharkly.
Sharkly describes itself as a work management system for People and Agents, with requirements, task state, discussion, execution records, and review kept together rather than scattered across private prompts and terminal sessions.
That doesn't mean every person is necessarily typing into the exact same chat window at the same moment.
In fact, Sharkly's documentation makes an important distinction between standalone Agent Chat and the collaboration happening around a Task.
Standalone Agent Chat belongs to the person who created that session. The task-based workflow is different: the Task becomes the shared record where people can collaborate around the work.
That distinction matters.
The goal isn't necessarily "put everyone into one giant chat."
The goal is:
Keep everyone working from the same source of truth.
How Humans and Agents Could Work Together
A realistic development workflow might look something like this:
Product requirement → Human planning → Agent execution → Human feedback → Agent adjustment → Human review → Completion
Let's make that more concrete.
Step 1: A person defines the task
A developer or product manager creates a task describing what needs to be done.
The task can contain the goal, description, acceptance criteria, priority, status, and other project information.
In Sharkly, a Task can also have a person responsible for the work and an Agent or Crew assigned to execute it.
Step 2: The agent starts working
The agent receives the task context and begins execution.
A task-backed run can include the task description, current status, project and sprint information, recent comments, agent instructions, skills, repositories, environment configuration, and runtime settings.
This is important because the agent isn't operating with just a single isolated sentence.
It has structured context around the work.
Step 3: A human adds context
While the work is progressing, a developer might realize something important:
"Don't modify the legacy authentication middleware. The mobile client still depends on it."
That information needs to become part of the work.
In Sharkly, task comments are designed for exactly this kind of discussion. Comments can contain new requirements, constraints, review findings, decisions, files, screenshots, or instructions for the task's Agent Assignee.
Step 4: The agent continues
The comment can trigger a follow-up run for the Agent assigned to the Task.
Sharkly's execution model allows eligible member comments to enqueue follow-up work, including while another run is active. The system can coalesce pending work so rapid comments don't create duplicate pending runs for the same Agent and Task.
This is a very different model from simply starting a new AI conversation every time requirements change.
Step 5: Another human reviews the result
The agent finishes.
Now someone needs to look at what happened.
Was the implementation correct?
Did the tests pass?
Did the agent misunderstand the requirement?
Is there something that needs to be changed?
The agent can leave a result as a Task comment linked to its execution, while the execution log provides additional information about the run.
The human then becomes the reviewer rather than just the person waiting for AI output.
Why Context Is Becoming a Project Management Problem
This is probably the biggest change AI agents introduce into development workflows.
We've always needed project management because software development involves multiple people, tasks, dependencies, priorities, and decisions.
Agents add another problem:
context continuity.
An AI agent can produce good work and still fail because it didn't have the right context.
Maybe the requirement changed.
Maybe another developer made a related architectural decision.
Maybe an edge case was discovered.
Maybe a previous attempt failed.
If that information exists only inside someone's private chat or terminal session, the rest of the team may not know about it.
That's where project management starts becoming more than a list of tasks.
The task can become the shared memory of the work.
In Sharkly, the Task holds the goal, state, assignee, comments, attachments, activity, and agent execution information.
That gives people and agents somewhere to return to.
What Should a Project Management Tool for Agents Actually Do?
I think this is where the definition of a project management tool for agents starts to differ from traditional project management software.
It doesn't necessarily need to replace everything a Jira-style tool does.
But it needs to understand that an agent is capable of actually executing work.
Here are some capabilities I would look for.
1. Assign work to both humans and agents
A task shouldn't have to assume that the executor is always a person.
The system should be able to represent human ownership and agent execution clearly.
Sharkly's task model supports People, Agents, and Crews as assignees.
2. Preserve context
The agent needs access to the relevant task information rather than receiving a disconnected prompt every time.
That includes requirements, comments, repositories, skills, and other execution configuration.
3. Keep execution history
If an agent makes changes, the team should be able to understand what happened.
Sharkly separates Task workflow status from Agent run state and maintains execution information such as queued, running, completed, failed, and canceled states.
4. Allow humans to intervene
Agents shouldn't operate as black boxes.
Humans should be able to add context, answer questions, provide corrections, review results, stop a run, retry work, or reassign a task.
Sharkly's workflow supports follow-up comments, human attention states, cancellation, retry, and reassignment.
5. Make handoffs possible
The person who starts a task shouldn't necessarily be the person who finishes it.
And the agent that starts the work might not be the agent that handles the next stage.
A project management system should make those transitions visible rather than hiding them inside private conversations.
From One Agent to Agent Teams
The next step becomes even more interesting when you stop thinking about one agent.
Imagine a software project where different agents have different responsibilities.
One agent handles implementation.
Another specializes in testing.
Another handles documentation.
Another investigates production issues.
Now the question becomes:
How do you coordinate all of them?
Sharkly uses the concept of a Crew for this.
A Crew combines a leader Agent with other Agents and People so that a complex Task can be assigned to a reusable team rather than a single executor.
This starts to look less like "AI autocomplete" and more like a development team with specialized capabilities.
For example:
Feature request
↓
Planning
↓
Implementation Agent
↓
Testing Agent
↓
Review
↓
Documentation Agent
↓
Human approval
The human doesn't necessarily need to manually orchestrate every transition.
The important thing is that the work remains connected.
The Agent Isn't the Project Manager
There's another distinction I think is important.
An AI agent performing a task doesn't mean the agent should become the manager of the entire project.
There is still a human responsibility for deciding:
- What should be built?
- Why are we building it?
- What constraints matter?
- What should be prioritized?
- What is acceptable?
- When is the work ready to ship?
The agent can execute.
The project management layer can coordinate.
The human can make the important decisions.
That separation is actually one of the reasons I think agent-based project management makes sense.
We're not trying to make the AI replace the team.
We're trying to make the team capable of working with more capable AI systems.
A Practical Human + Agent Workflow
Let's say a team wants to add a new payment method to its application.
Here's how I could see the workflow operating.
1. Create the requirement
A developer creates a task describing the payment integration and its acceptance criteria.
2. Assign the implementation
The implementation task is assigned to an appropriate coding agent.
3. The agent investigates
The agent examines the repository and determines how the existing payment architecture works.
4. The agent implements
It makes the required changes and runs the relevant tests.
5. A developer intervenes
The developer notices that the implementation doesn't account for an existing mobile workflow.
They add that information to the task.
6. The agent adjusts
The agent receives the follow-up context and continues the work.
7. QA reviews
Another person checks the implementation and asks for additional test coverage.
8. The agent handles the follow-up
The agent runs another execution based on the new requirement.
9. Human approval
A developer reviews the final result and decides whether it is ready to merge.
Notice what happened.
There wasn't a single giant prompt.
There wasn't a completely autonomous AI process.
And there wasn't a person manually copying every piece of context between tools.
Instead, the work moved through a shared task.
That's the model I find most interesting.
Turning Agent Work Into Team Work
Once AI agents start handling real development tasks, the conversation becomes bigger than the agent itself.
You need somewhere to keep the requirement, the context around it, the conversation, the execution history, and the eventual result. Otherwise, the work can easily become tied to one person's terminal or one private AI session.
This is where Sharkly.ai takes an interesting approach.
Instead of treating the agent session as the center of everything, the Task becomes the shared workspace around the work. People can contribute context and decisions, while the assigned agent handles the execution.
The different parts of the workflow have their own roles. An Agent defines how a particular type of work should be handled. A Computer provides the environment in which that work can run. The Runtime handles the actual execution. The Task then brings the work back into a shared context that the rest of the team can follow.
That separation is useful because the agent doesn't have to be rebuilt from scratch for every task.
A team might have one agent configured for backend development, another for testing, and another for documentation. Each can have its own instructions, Skills, repositories, environment, and Runtime configuration, while individual Tasks provide the specific requirements and context for what needs to be done.
That creates a different workflow from simply opening another AI chat whenever there's work to do.
The agent becomes a reusable capability.
The Task becomes the piece of work.
And the people on the team remain part of the process.
For teams experimenting with multiple agents, that distinction can become increasingly important. The challenge isn't just getting an agent to complete a task. It's making sure the work it does can be understood, reviewed, redirected, and continued by the rest of the team.
What Happens When the Agent Gets Stuck?
This is another place where human-agent collaboration matters.
Agents will still get stuck.
They can encounter a failing test, missing credentials, an unclear requirement, a dependency problem, or a situation where a human decision is required.
A useful system shouldn't hide that.
It should surface the need for human attention.
In Sharkly, an Agent can leave a Task waiting for a human reply or review. Failed or blocked work can also surface as an attention item in Inbox, where the responsible person can open the Task, respond, review the result, retry, or decide whether to reassign the work.
That's an important part of the workflow.
Autonomy doesn't mean humans disappear.
It means humans spend their attention where it is actually needed.
The Shift From AI Assistant to AI Teammate
I think we're approaching a point where calling every AI development tool an "assistant" becomes less useful.
An assistant traditionally waits for you.
An agent can take responsibility for executing a defined piece of work.
That creates a completely different collaboration model.
The team may eventually have:
Human developers
AI coding agents
Testing agents
Research agents
Documentation agents
Operations agents
And all of them may contribute to the same product.
The difficult part won't necessarily be finding an agent capable of writing code.
There are already many capable options.
The difficult part will be coordinating all that work.
Who assigned the task?
What context did the agent receive?
What did it change?
What happened during execution?
What does the next person need to know?
What requires review?
What should happen next?
Those are project management questions.
Final Thoughts
The interesting question about AI agents isn't simply whether they can write more code.
It's whether our development workflows are ready for them to become actual participants in the work.
If an agent can investigate a problem, modify a repository, run tests, and continue working across multiple steps, then treating it like a simple chatbot starts to feel limiting.
The better model is collaboration.
A person defines the goal.
An agent executes.
Another person adds context.
The agent adapts.
A reviewer checks the result.
Another agent can take over the next stage.
And the team remains connected to the entire process.
That's why I think project management for agents will become its own important category.
The goal isn't to remove humans from software development.
It's to create a workflow where humans and agents can work on the same problems without losing context every time responsibility changes.
AI can do more of the work now.
The next challenge is figuring out how we work together while it does.
Top comments (2)
Yep. Agents should not become the manager of the entire project.
That's one thing vibe coders ignore 😂