Part 2: the bridge connects the team. What can the team turn into something useful?
In the first article, I connected my personal assistant, Instinct, to OpenCode on my Mac. Instinct is the PM. OpenCode is the developer. I can text the assistant, it hands over the work, and the result comes back to my phone.
That solves the handoff. Now for the interesting question: what do you hand the team?
A video you bookmarked. A screenshot captioned "this looks weird." An email asking you to do the same little calculation again.
Usually, you translate each of those into a coding task yourself. Copy the request. Paste the context. Explain the answer. Repeat until the future of computing looks suspiciously like an office job.
The next step I want is to let the team carry that translation: an everyday thing goes in, something another person can use comes out.
You can give a coding agent browser tools through MCP or plugins. A coding agent that can look at a page, edit code and check the result is useful.
That is not the distinction I am making.
The distinction is who owns the conversation.
With tools attached to a coding agent, you are still talking directly to the developer. In this setup, I talk to a personal assistant, and it works with a separate coding agent. Instinct handles the request and the outside-world information relevant to it. OpenCode works in the repository and keeps the coding session.
MCP could be part of either side. It does not make the team idea redundant. Tools give an agent capabilities; the handoff gives those capabilities different jobs.
Giving the developer a browser is useful. Giving the developer a colleague is the part I find exciting.
You watch a video explaining an idea. Normally, the output is a bookmark and the feeling that you have been productive.
What if the output were something another person could use?
The examples below are illustrations of what the team could do with the right tools and access. They are not transcripts or a claim that these workflows all ship in the bridge today.
Say the video teaches a way to compare options. You send it to Instinct:
Research this method. Work with OpenCode to turn the useful part into a small interactive demo. Bring it back for review before we share it.
Instinct checks the accessible material and supporting sources. It separates the method from the sales pitch, identifies the assumptions, and helps choose a version worth building. OpenCode turns the brief into a demo with adjustable inputs, a worked example and checks for the results.
Now your friend can enter their own options and try the method. They do not need to watch the video, find the useful bit or translate it into a spreadsheet first.
The interesting transformation is not video to summary. It is video to something you can put in somebody else's hands.
Someone sends you a screenshot of a mobile page with the message every developer loves:
This looks weird.
A beautifully precise specification. We should frame it.
Instead of becoming the translator between that message and your coding agent, you could give the team the screenshot and the page to inspect:
Work out what's wrong, fix the clear problem, and give me a working preview I can send back for review. Ask me before changing the design itself.
Instinct turns "weird" into something observable: the navigation covers the main action, or the layout clips at a narrow width. OpenCode makes the scoped change. With visual access, Instinct checks the result and sends any remaining problem back to the coding session.
The useful output is a working preview the other person can open on their own phone. They can try the interaction, rather than approving a screenshot and discovering later that the button is decorative.
A vague complaint has become a corrected experience someone can use and review. The team has carried the translation; you make the decisions it cannot.
Then there is the email that keeps coming back because everybody is doing the same little calculation by hand.
"Which option fits these requirements?" followed by a list of constraints. Someone opens a sheet, copies the inputs, checks the rules and writes the answer. Next week, the ritual returns with different inputs. Congratulations: your inbox has a manual API.
You could ask the team:
Look at this recurring request. Help me turn the agreed rules into a small tool people can use themselves, without exposing the emails or inventing any rules.
Instinct works out which inputs matter, checks the rules with you, and removes the private context from the brief. OpenCode builds a utility around the approved logic, with examples and checks.
The output could be a simple eligibility checker: someone enters their requirements and sees which options fit, along with the reason. Unresolved cases stay unresolved instead of getting a confident answer made up for them.
Now the next person gets a tool to try, not another explanation to copy. The emails are not being published; the approved process is being turned into something reusable.
This is the same team dynamic in a different shape. Instinct understands the work around the code. OpenCode builds the thing. You approve the rules and any sharing.
None of these examples is impossible without two agents. The appeal is that the person no longer has to turn every source, complaint and recurring request into a technical brief by hand, then carry every answer back again.
The goal is to get interrupted for the right reasons.
"Which of these designs do you prefer?" is a useful interruption.
"Please copy my last message into the other app" is a cable pretending to be a conversation.
A coding response might say that part of the request is finished, but another part depends on a decision. That should not leave you decoding a terminal transcript on your phone. The PM should bring you the decision in plain words, then take your answer back to the coding session.
A fix might pass a code check but still look wrong in the browser. The PM should be able to return that evidence to the developer rather than declaring victory because the last sentence sounded confident.
"It works on my machine" is an old classic. We do not need to replace it with "it works in my summary."
The roles keep their context. The assistant stays with the request. The developer stays with the code. A follow-up can return to the same coding session, rather than introducing the project to an amnesiac stranger every time you send a message.
That is what I want from this team: work that keeps moving between my decisions, rather than work that moves only when I paste something.
The bridge carries tasks to OpenCode on the machine and returns the output, branch and session information. It is the connection between the teammates, not a third genius hired to supervise the other two.
It also does not magically become a browser, an always-on computer or a quality guarantee. Visual review needs visual tools. The machine needs to be available. The result still needs checking.
The first version provides the conversational coding handoff. The richer team workflow is what I want to build around it, with clear briefs, useful evidence and questions coming back at the right moment.
Personal assistants and coding agents will keep improving at different things. I want to benefit from both, rather than wait for one product to become the best at everything.
A better personal assistant could understand the request and the context around it more clearly. A better coding agent could turn that brief into a better implementation. The handoff is what lets those improvements meet.
That is why I want the pairing to become portable: keep the team, change either teammate when there is a good reason. Instinct and OpenCode are the pair I use today. Other assistants and coding agents would need their own integrations; swapping them is the direction, not a feature every combination supports already.
I am not betting on one platform winning. I want to ride both improvement curves.
The source is here: https://github.com/sharkwani/instinct_openCode_bridge