#Communication
Communication patterns define how agents exchange information and coordinate actions. Posts cover A2A protocol-based inter-agent communication, Microsoft Agent Framework message routing, and the architectural patterns that enable agents to collaborate without tight coupling.
9 posts tagged with communication. ← All posts
The finale of "The Software Architect's Path" — why the non-technical skills decide whether a good design ever ships, and how communication, influence, mentoring, and humility turn a diagram into a system a whole team actually builds.
The capstone: the non-technical skills that make or break an architect — communication tailored to the audience, influence without authority, leading technically while staying hands-on, mentoring, and avoiding the ivory tower.
An FDE's code only matters if the customer trusts them enough to adopt it — the relationship is not soft-skills garnish, it's the delivery mechanism.
An FDE's code only lands if the customer trusts them: earning trust in small kept promises, speaking the customer's outcomes and vocabulary, managing expectations relentlessly, navigating the org (champion/skeptic), and delivering bad news well.
How to write code-review comments that improve the code and the relationship at the same time — commenting on the code not the coder, labeling severity so the author knows what blocks, asking instead of decreeing, teaching the why, and knowing when a thread belongs on a call.
Writing review comments that improve the code and the relationship: comment on the code not the coder, be specific and actionable, label severity (nit/suggestion/blocking), ask questions when you lack context, and pick your battles.
Being right is not enough to change anything. Every engineer has watched a worse idea win because its advocate was more persuasive, more trusted, or simply better at bringing people along — and concluded, wrongly, that this is unfair politics they want no part of. But influence isn't manipulation; it's the skill of helping good ideas actually happen through other people. In any organization, your impact is bounded not by the quality of your ideas but by your ability to get others to understand, trust, and act on them.
Being right is not enough to change anything. Every engineer has watched a worse idea win because its advocate was more persuasive or trusted. But influence isn't manipulation — it's the skill of helping good ideas actually happen through other people, and your impact is bounded by it.
The conversations we most want to avoid are usually the ones that matter most — telling a colleague their work isn't good enough, raising a concern with your manager, addressing a conflict that's festering, giving feedback that might not be welcome. Avoiding them feels safer in the moment and is almost always worse over time: problems grow, resentment builds, and the unsaid thing poisons the working relationship. Emotional intelligence doesn't make hard conversations easy, but it makes them possible to have well — which is a learnable skill that changes everything downstream.
The conversations we most want to avoid are usually the ones that matter most — telling a colleague their work isn't good enough, addressing a festering conflict, giving unwelcome feedback. EQ doesn't make hard conversations easy, but it makes them possible to have well — a learnable skill that changes everything downstream.
Empathy is where emotional intelligence turns outward — and where it becomes genuinely useful to everyone around you. It's the difference between an engineer who "wins" a design debate by being loudest and one who understands what each person actually needs and finds a solution everyone supports; between a code review that makes someone defensive and one that helps them. Empathy isn't sentiment. It's the practical skill of accurately understanding what other people think and feel, and it's the foundation of every effective interaction.
Empathy is where emotional intelligence turns outward — and where it becomes genuinely useful to everyone around you. It isn't sentiment; it's the practical, learnable skill of accurately understanding what other people think and feel, and it's the foundation of every effective interaction.
An objection feels like a rejection — the customer pushing back, resisting, saying no. The mental shift that transforms selling is realizing an objection is usually the opposite: a sign of engagement, a real concern surfaced, an invitation to address the thing standing between them and yes. Handled with the pushy-sales playbook (overcome it, pressure through it), objections end deals. Handled with genuine understanding, they're how deals get closed — by resolving the real concerns that were always going to decide the outcome.
An objection feels like a rejection — the customer pushing back. The mental shift that transforms selling is realizing it's usually the opposite: a sign of engagement, a real concern surfaced, an invitation to address the thing standing between them and yes. Handled with genuine understanding, objections are how deals get closed.
The instinct of every enthusiastic builder in a sales conversation is to talk — to explain the product, demo the features, make the case. It's almost always the wrong move. The best salespeople do the opposite: they ask, and they listen. Discovery (understanding the customer's actual problem) and qualification (determining whether they're even a real fit) are the unglamorous early stages where good selling is truly won or lost — and where an engineer's diagnostic instincts, properly aimed, are a genuine advantage.
The instinct of every enthusiastic builder in a sales conversation is to talk. It's almost always the wrong move. The best salespeople ask and listen. Discovery (understanding the customer's actual problem) and qualification (whether they're even a real fit) are where good selling is truly won — and where an engineer's diagnostic instincts are an advantage.
The reference architecture distinguishes request-based and message-driven agent communication. For in-process orchestration, the workflow IS the broker — and A2A is just the wire format.
All posts on this site are written by Pratik Dhanave, an Agentic AI Architect with 7+ years building production distributed systems, multi-agent AI platforms, and cloud-native infrastructure. About the author → Each article includes working code, architecture diagrams, and references to the specific frameworks and standards discussed. Browse all posts or explore related topics using the tag cloud above.