PROFESSIONAL PRACTICE AND COLLABORATION

LEARNING GOALS By the end of this chapter you will be able to work with the teams that own observability and governance. You will be able to write a short design-decision document. You will be able to share knowledge so that lessons are not lost. You will be able to build a sustainable routine for keeping up with a fast-moving field. WORKING ACROSS TEAMS No harness lives alone. Other teams own the places where your agent's data is stored and the rules your agent must obey. An observability team may own the tracing systems and dashboards. A governance team, sometimes called a security or risk team, may own the rules about permissions, data handling, and approvals. Good collaboration means asking before building. If you want to give an agent a new capability, such as sending email, you should first show the governance team the permission scope you propose, and show the observability team what new data the capability will emit. Getting their sign-off before writing code is cheaper than rebuilding after a rejection. It also builds trust, because those teams see you treat their concerns as design inputs, not obstacles. When you disagree, bring evidence, such as a trace or a test result, rather than opinions.