INSPIRATION
A client, an engineer, and a manager can read the same sentence and walk away with three different understandings.
"We want a simple member system that integrates with our current website, ideally launching next month."
The client hears a small, quick project. The engineer hears a dozen unanswered questions: How do users log in? What is the current site built on? What does "simple" mean, and to whom? The manager hears a deadline. Nobody is wrong. They are just standing in different places.
Every role and professional background shapes what people care about, the words they use, what they assume is obvious, and what they are worried about. When those perspectives collide, the result is predictable:
- Communication cost: endless clarification rounds, meetings to explain the last meeting
- Lost trust: overpromises, hidden assumptions, and "that's not what I asked for"
- Slower execution: rework, delays, and scope disputes
Some people spend their entire workday standing in that gap. Product managers, project managers, and solutions architects are the boundary spanners of every organization. They translate client needs into engineering specs, engineering constraints into executive risk, and internal decisions into proposals clients will accept. They are the human translation layer, and when a misunderstanding happens, they carry the cost.
This problem became real to me through my master's capstone at McGill. I am part of a student team working with the AI and IT team of a global mining company to build an AI assistant for data quality. The assistant is used by members of the AI and IT team themselves: it summarizes data quality problems and helps them communicate those problems to their stakeholders. My role is mainly UI design, so my job is to decide how those summaries are structured and presented, so the team can take them straight into conversations with others.
Working on it, I saw how much of the AI and IT team's work is actually communication. The same data issue has to be explained differently to each stakeholder:
- Business stakeholders need to know how it affects decisions and reporting.
- Hardware and software engineers need to know where the problem originates and what to fix.
- Other data teams need to know whether it affects their pipelines and who owns the fix.
The assistant's real value is not only detecting problems. It helps the team frame each issue for the right audience, so the teams who can actually fix it are able to step in and act. Framed the wrong way, the same facts get ignored or cause unnecessary alarm.
That is when I realized this is not one company's problem. Every organization has technical teams who must explain their work to business, engineering, and partner teams. Even a one-person company constantly switches its message between business functions: sales, delivery, finance, technology, and operations, often in the same day.
My background spans business administration, psychology, programming, and UX design, and I have learned that projects rarely fail from a lack of skill. They fail in the space between people, teams, and organizations.
General AI tools do not close that space. In many cases, they make it wider:
- They make things up. When a request is incomplete, they fill the gaps with confident guesses and present them as facts, including requirements nobody asked for, timelines nobody agreed to, and details that are simply wrong.
- They stay vague. Their output often sounds polished but says little: generic best practices, "it depends" without saying on what, and summaries no one can act on.
- They ignore who is listening. The same answer is given to an executive, an engineer, and a client, even though each needs something completely different.
- They overpromise. Asked to write a proposal, they make everything sound easy, fast, and certain, which is exactly how trust gets broken later.
For someone whose job is to bridge perspectives, this is risky. Every made-up detail or vague claim they pass along puts their own credibility on the line.
I wanted a tool that does the opposite: make every perspective's hidden gaps visible, keep every claim specific and traceable, and turn a request into a plan and an agreement everyone can work from.
WHAT IT DOES
CommonGround is a planning and communication supporter for boundary spanners: product managers, project managers, solutions architects, and technical teams such as AI, IT, and data teams. It deconstructs a request, weighs it against the team's internal reality, and turns it into one plan and one agreement that stakeholders and the team can work from, communicated to each audience in their own language.
PERSPECTIVE LENS
Each stakeholder is modeled by what they care about, the language they use, what they take for granted, and what they worry about. CommonGround translates between these lenses instead of forcing everyone into one vocabulary.
THE WORKFLOW
- Deconstruct: Paste a request plus internal notes. CommonGround summarizes it, then finds what is ambiguous, missing, silently assumed, or in conflict with the team's situation (for example, a holiday deadline vs. a team that is already booked).
- Clarify: Up to 5 high-impact multiple-choice questions, one decision each. Skipped questions stay open; the AI never answers them for you.
- Plan and align: A shared agreement where every requirement shows its source, plus a phased team plan with owner roles, dependencies, and internal delivery risks.
- Communicate: Drafts for clients, teams, or leadership that only ask each reader for what they need to decide, confirm, or provide. Detailed tasks stay in the team plan.
- Check before sending: An integrity check flags overpromises and internal-information leaks. Users can edit the draft, apply or dismiss each suggestion, re-check, and copy the final text.
TRUST BY DESIGN
- Traceability: every requirement is tagged as the requester's own words, the user's answer, or an AI inference marked as an assumption.
- No silent assumptions: every assumption must be confirmed, flagged for the requester, or removed before communication is unlocked.
- Internal / external boundary: internal requirements, plan items, and risks are filtered out before drafting for external audiences, and every draft is checked again for leaks.
- Human in the loop: CommonGround drafts and warns. It never sends anything on your behalf.
- Your data stays yours: CommonGround runs on open models via Nebius and stores no user input.
HOW I BUILT IT
CommonGround is a multi-step agentic pipeline built on Nebius Token Factory, using its OpenAI-compatible API. Each step uses the right-sized NVIDIA Nemotron model:
- Classify input: Nemotron 3 Nano
- Diagnose gaps, assumptions, and internal conflicts: Nemotron 3 Ultra, because finding what is not said needs deep reasoning
- Clarifying questions: Nemotron 3 Nano
- Shared agreement and team plan: Nemotron 3 Super
- Audience-specific drafts: Nemotron 3 Super
- Integrity and boundary check: Nemotron 3 Super
Stack: Python, Streamlit, Pydantic schemas for every step, and the OpenAI SDK pointed at Token Factory. A sidebar trace shows each call's model, time, tokens, and retries.
Trust is enforced in code, not just in prompts:
- Every requirement carries a source field and a visibility field.
- Any quote attributed to the requester is verified against the original input; fabricated quotes are downgraded to assumptions.
- Invalid JSON is sent back to the model with the validation error for an automatic retry.
Early evaluation: I wrote three fictional demo cases and hand-labeled the issues an experienced PM should catch. On the main case (12 labeled issues), the diagnosis step found about 9-10 in the first run and about 11-12 after prompt iterations, including privacy, admin ownership, and payment compliance. This is one case, not a benchmark, but it guided every prompt change.
CHALLENGES I RAN INTO
- Empty answers: my first Nemotron test returned nothing, because reasoning used up a small max_tokens budget before the final answer.
- Stopping the model from inventing facts: clarifying options once stated that a specific POS vendor had no public API. A prompt rule now forbids options that assert unknown facts, and options became neutral ("Can your POS sync in real time?").
- Bundled questions: the model combined budget, design, and platforms into one question and asked about process instead of the request. Tighter rules fixed both.
- Latency: the clarify step took 25.9s on Super. I tested Nano (20.5s) and Lightning (51.4s). The delay came from reasoning length, not model size, so I kept Nano.
- Communication vs. documentation: early drafts copied the whole plan into client emails. I redesigned drafts to include only what each reader must decide, confirm, or provide.
- Solo, in 10 days, so every feature had to earn its place.
WHAT I LEARNED
- The hardest part of cross-perspective communication is detecting what is missing, not rephrasing. In side-by-side tests, only Ultra raised the hidden business-model question (one cafe chain vs. a platform for other cafes).
- Trust must be enforced structurally, with schemas, source tags, and verification, not just requested in a prompt.
- Model tiering is a product decision, and the right model depends on the task: a model named Lightning was the slowest for my structured step.
- Token Factory's OpenAI-compatible API made switching and comparing Nemotron models a one-line change.
- Communication is not documentation: planning detail belongs in the team plan, and each message belongs to its reader.
WHAT'S NEXT
- More lenses: design and engineering, marketing and product, data teams and business users.
- Project memory: each project's glossary, stakeholders, and past agreements.
- Integrations: Slack, email, Jira, and Notion, so alignment happens where work already happens.
- Freelancers and solo founders, who play every boundary-spanning role at once.
