This is Part 5 of 8 in The Projects AI Makes Possible, a series about building a private almanac from a 1992 geography game with a coding agent. In Part 4: Learning to Trust an AI Agent With the Goal, Not Dictate Every Step, I gave the agent the original regional maps and woke up to a freshly generated matching set with colors and styling of my choosing. Maps could be compared by sight. The country text introduced a less obvious problem: a rewrite could sound good while losing critical information.

“Language is the source of misunderstandings.”

Antoine de Saint-Exupéry, The Little Prince

By this point, we had extracted all the country articles from the game, however they were all individual, discrete fact based sentences. I wanted to turn them into almanac prose that would have consistent sections and ordering across all countries. I needed to preserve the original information and later fill in additional data to give all the country pages roughly the same level of detail.

The agent rewrote the country facts into a consistent structure across all the pages. In the game data, the facts appeared in different orders from one country to another: some led with history, others with geography, and so on. I wanted to rewrite these to naturally be in the same order instead across all countries, under subheadings, in the almanac.

When the rewrites were ready for review, I looked at Greece to see how it had fared. The first version turned several short bullets into a very smooth-sounding overview:

Greece is a mountainous country with a rugged coastline and thousands of islands. Athens is its capital, and ancient Greece made lasting contributions to philosophy, science, drama, and art.

It sounded fine. Nothing in it was obviously false. It was short, clear, and grammatically complete.

Then I looked at the source article.

The original described Greece’s mountains, rugged shoreline, and thousands of islands. It named Crete, Rhodes, Delos, and Mykonos. It included Macedonian rule beginning in 338 B.C., followed by roughly 2,000 years of occupation. It connected Athens and Sparta with philosophy, science, drama, and art. It named the Acropolis and the Parthenon and preserved the words Hellas and Hellenes.

The broad outline had survived. Nearly every name, date, and example was gone.

The Rewrite Sounded Fine… But It Wasn’t

That comparison made me realize I had simply assumed that paraphrasing would keep all the details, but I needed to be explicit: what I really wanted was lossless paraphrasing. Every number, date, place, example, comparison, and factual claim had to survive in the new prose.

This is noteworthy because my broad-strokes instructions to the agent caused friction. Contrast this with the review pages, maps, and image decoding, where I gave high-level goals, the agent stayed quite well aligned, and my unspoken assumptions held. Here, I had omitted a critical assumption and had to backtrack to make it an explicit requirement: the rewritten facts had to contain everything the source noted.

This introduced another issue. I could proofread the Greece entry because I was comparing one paragraph with another. Proving completeness across dozens of almanac entries was going to be difficult, especially given that I didn’t want a word-for-word copy. By definition, I wanted a paraphrase and reorganization of the data.

Mapping Sources to Destinations

Once again, I worked with the agent as a partner and, as funny as it sounds, asked for its opinion about my proposed solution. I proposed giving every source sentence a unique identifier based on its location. A sentence might be identified as:

Greece Fact 1, Sentence 1

Its rewritten destination might be:

Greece, Natural Environment, Sentence 1

The structure depended on the relationship between them. Each old sentence had to point to a new sentence, so if we had a missing destination I would know. Then, for completeness, the agent could check whether each fact from the source was also present in the destination.

The review format became:

• Old location
• Old fact
• New fact
• New location

The agent implemented the relationship in a local database and built a tablet-friendly review page around it.

Instead of asking whether the new Greece article felt complete, I could inspect one source sentence at a time. I could flag a weak paraphrase, search by country, filter to pending rows, and distinguish source-backed rewrites from newly researched facts.

A newly added fact had no old location and carried its own source reference. I had asked the agent to expand the facts using Wikipedia and other public sources so every country had roughly the same kinds and depth of information, beyond what the game contained. An original fact without a new destination showed up as pending.

In the review snapshot, the system accounted for 858 source sentences across 61 entries, plus 25 added-only facts. No source sentence was left pending.

Initially, the database and review page gave me a way to double-check the agent’s rewrites. After I was satisfied with a few spot checks, I decided once again that I didn’t need to do this work myself! From then on, the same structure gave the agent a way to check its own work.

It could query for source sentences without destinations, run coverage checks for names, dates, numbers, and other details, repair the gaps it found, and regenerate the review page. The agent was increasingly finding and resolving omissions independently before I reviewed the next result.

Then and Now, Together

The quick facts exposed a related issue. The game had captured the world in the early 1990s. Greece used the drachma then; today it uses the euro. Populations, flags, capitals, and country names likewise reflected that time.

However, I didn’t want an almanac stuck purely in the past. It also needed to be understandable now. Replacing every old value would remove game-era context, while presenting every old value as current would be misleading.

The agent built another review page that placed extracted game values beside current structured references.

That comparison let us make field-by-field decisions. The public fact box could show a current population and currency while preserving a former currency or 1990s flag description where it helped connect the almanac to the game.

The same review also exposed fields that looked simple but were not. Head of state changes frequently. Official-language labels can hide federal, regional, or de facto distinctions. As I’ll share in future articles, this ultimately led me to have a small subset of information in a “Fact Box” section with items such as capital, currency, etc. – but omit, for example, head of state, since that changed much more frequently.

Now We Could Trust It

The country rewrite began as a request for better prose. Reviewing the first country made me realize we first needed to deal with data integrity.

After refining the lossless paraphrasing requirement and aligning the sentence-level relationships, the agent turned that idea into a database, review pages, filters, and coverage checks. My review helped clarify what I actually needed, and the agent could then use the review database by itself (themselves?) to audit later batches without waiting for me to identify every gap.

The system could now account for every extracted country sentence. The main country facts had been paraphrased into new prose and reorganized into subsections without dropping the information from the game. Where the passage of time mattered, the almanac could place 1990s context beside present-day facts instead of pretending they described the same moment.

The result was a real almanac we could use. A country page gave us a clear overview, preserved the substance of the game article, and added enough current context to also provide a little bit of education in the process.

But Wait…There’s More…Data??

Playing with it revealed the next gap. We could open a country and learn about it, but searches for some phrases mentioned during a case still returned nothing. In Part 2 I casually mentioned setting aside some “clues”. Those missing clues lived in a much larger collection of fragments, shared descriptions, and lines that only made sense beside the line before or after them and turned out to be critical as well.

The broad set of country facts was complete and usable. Now we needed to do the same with the standalone clues.

“You want it to be one way. But it’s the other way.”

Marlo Stanfield, The Wire

On a trip with my parents, we had a car for the day and a rough list of places we wanted to see.

Just before we left, an auntie came over and told me how nice it was to see me again. Then she smiled and said, “It’ll be fun. Let’s go outside and join your mom in the car.”

I took that to mean she was joining our trip at the last minute. I was surprised, but I did not mind.

Except every stop seemed to need her approval.

My mom would suggest somewhere, auntie would say it was too far or that another stop made more sense first, and the plan would change. It was never a big argument. The day just kept getting rearranged around what worked for her.

At a couple of stops, auntie did not even come inside with us. She stayed in the car until we were ready to go again.

My mom is always incredibly kind to our friends and family, so at first I assumed she was simply being a generous host. But after the plan changed a few times, it started to seem like we were deferring a bit too much to someone who, as far as I understood it, was just tagging along for the day.

After this happened a few times, I finally asked my mom why we were checking with auntie about every stop. I thought she was coming with us for the day.

My mom looked at me. “Sid, this is her car.”

My parents had planned to hire a car for the day, but that fell through. Auntie was already planning to go into the city, so she told them she would not mind if we joined her. She was taking us along, adjusting her route, and waiting while we made our stops.

I Had The Roles Backwards

What confused me was not the itinerary itself. It was how someone I thought was a guest had somehow become the decision-maker.

In my version of the day, my family had the plan and auntie was joining us. Of course she could have preferences. But every time my mom deferred to her, it felt like someone along for the ride had suddenly taken control of it.

Once I understood what was happening, my mom’s behavior made sense. Auntie was spending the day taking us around. Of course we were going to check what worked for her.

I Have Seen This At Work Too

The same role mismatch shows up at work. Two people can leave the same meeting each believing they own the decision, then give the team conflicting direction. Or everyone can agree on the general direction and still leave without knowing who is responsible for driving the next steps. That ambiguity can turn an ordinary disagreement into a conflict over authority, or leave a decision sitting still after an otherwise useful meeting.

DACI gives those different responsibilities names. The Driver owns the work required to get the decision made: coordinating stakeholders, gathering the necessary information, addressing open questions, and keeping the process on schedule. The Approver is the one person who makes the final call. Contributors provide expertise and recommendations, while the people who are Informed need to know the outcome because it affects their work.

When those roles are unclear, the team is working on two problems at once: the problem itself and an alignment problem about who is responsible for what. More context may improve the discussion, but it will not tell anyone who should move the decision forward or make the final call.

Once the roles are clear, the conversation gets simpler. Everyone knows whether the decision is still open, what input is needed, who will make the final call, and when. People can disagree without being confused about their role in the decision.

That was the missing piece on our day trip. Everyone except me understood the arrangement. One sentence at the start would have changed how I read every conversation: “The person we planned to hire fell through, so auntie is doing us a favor letting us join her while she goes into the city today.”

With that context, I still would have had opinions about where we should go. But I would have known I was the passenger – and been grateful that auntie was letting us tag along.

“Mr. Watson—come here—I want to see you.”

Alexander Graham Bell, 1876

I was talking with a friend who also spends a lot of time working with AI agents. We started comparing our setups: the instructions we had accumulated, the prompts we reused, and the small decisions that had made our workflows work better over time.

It was a fun conversation, but we both had far more context than we were going to reconstruct from memory while we talked.

Later, I went home and sat down at my desk. I was still thinking about the conversation when I had an idea.

My working model lives in an Obsidian folder. It is not one polished process document. It is a collection of files, notes, instructions, examples, and smaller sub-workflows that have accumulated as I have worked with my agents.

What if I had my agent package the whole thing into one markdown file that I could send him?

I asked it to bring the material together without sanding off all the detail. The file covered how I turn a vague idea into a project, how I use Technical Design Docs, what makes a ticket title useful, what belongs in a ticket description, when I use milestones, how much context feels like enough, and when planning should finally turn into coding.

I thought of it as a one-pager in the sense that it was now all on one page, not in the sense that it was short.

I was excited about the idea, so I sent it to him.

“Don’t read this. Give it to your agent.”

Then He One-Upped Me

He was amused, and I think he was as excited by the idea as I was. But he did not simply hand the file to his agent and forward me whatever summary came out.

He had his agent analyze my workflow against his own. Then he read the analysis, talked through it with his agent, added his own reactions and context, and sent me back the combined thoughts from both of them.

I thought I had done the clever thing by packaging my workflow for his agent. He turned it into a conversation with his agent and sent back something better.

Have your agent call my agent.

It is a ridiculous sentence, but look at what had just happened. My agent packaged my workflow, his agent picked it apart, and my friend sent back the combination of what his agent noticed and what he thought about it. Honestly, that was much more useful than the two of us trying to explain every file and sub-workflow over a call.

A Diff Between Two Ways Of Working

What came back was more useful than a summary of my files. It showed where our approaches were similar, where mine was more explicit, what he was doing that I was not, and which ideas might be useful to borrow without declaring one process better.

It was almost like getting a diff between two ways of working.

Personal workflows are not code, of course. An agent can misunderstand why a preference exists, make a small difference sound important, or recommend something that does not fit the person receiving it. Neither of us wanted to adopt the other person’s process wholesale.

But neither of us had to read a giant folder cold and somehow know what mattered. We could get closer to the questions we actually wanted to discuss: Why do you structure projects that way? When does a design document help, and when is it just overhead? What information lets an agent keep working without stopping to ask another question?

I sent my friend a file because I was excited about my idea. He sent back a better version of the experiment. I am still deciding what to steal.

“Bad news does not get better with age.”

I remember walking with a colleague as he was heading into a meeting. As we got close to the room, he said something like, “Well, I hope they don’t ask about Project X.”

I understood the feeling. Nobody enjoys walking into a room hoping to defend a messy project, and nobody wants the awkward question, the uncomfortable pause, or the moment where everyone turns toward the part of the work that is not going well.

However, this instinct is backwards: you want the hard questions so you can explain what you know, what you do not know, what is being done, and what decision is needed, because the alternative is not silence: the alternative is that people talk about the problem when you are not there.

The Conversation Will Happen Somewhere

When a project is in trouble, silence is not neutral.

• Worried stakeholders will try to make sense of the situation.
• A confused team will fill in gaps.
• Leaders without enough information will build their own story from whatever signals they can see.

Avoiding the hard question does not make the organization less concerned; it makes the organization less informed. A hard question in the room gives you a chance to replace guessing with understanding. It also gives you a chance to show what responsible leadership looks like: say what is late, name the tradeoff, identify the dependency, make the needed decision explicit, and when you do not know yet, say what you are doing to find out.

Hard Questions In One-On-Ones

With your own team, an engineer may bring you a problem, a concern, a fear, or a messy early signal: the technical direction may be shaky, a teammate may be struggling, the deadline may be less realistic than people have been saying, a partner team may be frustrated, or the engineer may be worried they are not the right person for the work.

None of that is fun to hear, and it is still much better than not hearing it. This is where Stephen Covey’s habit, “seek first to understand, then to be understood,” matters in a very practical way: before I explain, defend, or solve, I need to understand what they are seeing and why they are worried.

If the problem is real and your team does not bring it to you, you still have the problem. You just have it in the dark. By the time it surfaces, you may discover that you have two problems: the original technical or project problem, which has been sitting unaddressed, and a trust problem, because your team did not feel safe enough, clear enough, or supported enough to bring it to you earlier.

Psychological safety can sound like a buzzword until you have worked on a team that lacks it. On that kind of team, risks stay hidden, people polish status, engineers wait until they are certain before raising concerns, and problems arrive late, fully grown, and harder to fix.

On a healthier team, people can say, “I am worried about this,” before they can fully prove it. They can ask for help early, surface risk while there is still time to change the plan, and trust that the first response will be curiosity instead of blame. That is not just better for morale; it is better operationally.

Make The Questions Welcome

You cannot simply announce that hard questions are welcome and expect people to believe you, because people watch what happens after the question.

If someone raises a concern and gets punished, dismissed, mocked, buried in defensiveness, or handed the entire mess alone, the lesson is clear: do not bring problems early.

A different lesson forms when the response is curiosity, clarity, shared ownership, and action. That does not mean every concern is correct. Some hard questions are unfair, some framings are wrong, and some worries are missing context. The first move should usually still be to understand: what are they seeing, what are they worried will happen, what decision do they think is needed, and what are we missing?

The Question Is A Signal

A hard question is a warning light, an invitation, the first visible sign of a risk that has been growing quietly, and a chance to build trust by facing the truth directly.

As a leader, I want that signal while it is still useful. I want the engineer to tell me before the project is fully off the rails. I want the stakeholder to ask while there is still time to reset expectations. I want the awkward topic in the meeting before it becomes the hallway narrative.

Early in my career, if I hit a blocker, my attention went straight to the technical surface area. What is broken? What changed? What do I need? Who owns the dependency? How do I explain why my part cannot move?

Those are still useful questions. They are just not enough.

Today, when I see a roadblock, my mind goes somewhere broader almost immediately: what does this mean for the project, for the critical path, for the people depending on this work, and for the decision someone now has to make?

That is the real responsibility in cross-functional communication.

The Work Is Bigger Than Your Part

Engineering work rarely fails only inside engineering.

A technical blocker becomes a missed launch. A vague requirement becomes a product surprise. A dependency delay becomes a planning problem. A quality concern becomes a support burden. A tradeoff hidden inside implementation becomes a business decision that no one realized they were making.

If you only communicate the engineering detail, you may be accurate and still not be useful.

Your partner in product, design, support, sales, marketing, finance, legal, or leadership is usually not asking, “can you narrate the implementation?” They are asking, “what does this mean, what are our options, and what should we do next?”

Ah, To Be Young And Focused

I can say this because I have been the engineer who missed it.

There is a younger version of me who thought the job was to be technically correct, explain the root cause, and wait for everyone else to understand why the conclusion was obvious. Ah, to be young and innocent again.

The problem was not that the technical explanation was wrong. The problem was that I was still communicating as if my local context was the whole context.

It was not.

Translate The Blocker Into The Decision

When something changes, the most useful cross-functional communication usually includes four things:

• What happened. The plain-language change in the situation.
• Why it matters. The impact on timeline, scope, risk, quality, customer experience, or team capacity.
• What options exist. The real paths forward, including the tradeoffs.
• What decision is needed. Who needs to decide, by when, and what happens if no decision is made.

That structure sounds simple because it is. The hard part is remembering to do it when you are deep in the weeds and annoyed that the weeds exist.

For example, “the API is late” is not enough.

Better is: “The API we need for checkout changes is now expected Thursday instead of Tuesday. That puts the Friday demo at risk. We have three options: stub the API and show the happy path, move the demo, or reduce the demo scope to the parts we can validate end-to-end. My recommendation is to stub for the demo but not call the feature launch-ready until we test against the real API.”

That is a different conversation. It gives people something to do.

Your Job Is Not To Make People Technical

A common engineering mistake is trying to pull every stakeholder all the way into the implementation details.

Sometimes that is necessary. Often it is a tax.

Your job is not to make every partner think like an engineer. Your job is to carry enough of the technical reality into their context that the group can make a good decision.

That means using words that survive outside the codebase. It means naming uncertainty clearly. It means separating facts from guesses. It means explaining the consequence of doing nothing. It means making the tradeoff visible without making the room decode it from a stack trace.

Cross-Functional Trust Is Built In Moments Of Friction

Everyone enjoys alignment when the plan is working.

The real trust gets built when the plan breaks.

If you communicate early, clearly, and with ownership, stakeholders learn that you are not just protecting your own work. You are protecting the outcome. They learn that you will not hide risk until it becomes crisis. They learn that when you raise a concern, it is because there is a decision to make, not because you enjoy being difficult.

That reputation compounds.

Over time, people stop hearing your updates as engineering noise and start hearing them as useful signal.

What Ownership Sounds Like

Cross-functional ownership sounds different from technical commentary.

It sounds like:

• “Here is the risk I see, and here is who it affects.”
• “This is still solvable, but the tradeoff is scope versus date.”
• “I do not think this is ready to promise externally yet.”
• “If we choose speed here, we should explicitly accept the cleanup work later.”
• “I can make the technical call, but this part is a product/business decision.”
• “No decision by Wednesday is effectively a decision to delay.”

Notice that none of those sentences require the listener to become technical. They require the engineer to become accountable for context.

The Responsibility

Your responsibility in cross-functional communication is not to say everything you know.

It is to say the useful thing at the useful level, early enough that people can still act.

That often means lifting your eyes from your part of the system to the whole system: the project, the customer, the timeline, the team, the risk, the stakeholder, and the decision that is quietly waiting to be named.

The work may start in code, but the outcome rarely stays there.