--- title: "Agentic Engineering: Context, Guardrails, and Creativity" author: "Port Webinar — Tomas & Zach on taming agentic chaos" description: "Welcome to this webinar about agentic engineering — context, guardrails, and creativity. I’m Tomas, product solutions lead at Port, with a background in DevSecOps and prior experience as a solutions..." source: "https://adhenawer.net/posts/original/agentic-engineering-context-guardrails-creativity.html" lang: en --- TL;DR · key points 1. Welcome to this webinar about agentic engineering — context, guardrails, and creativity. 2. Before we dive in, we wanted to learn the current state of agentic engineering in your organizations. 3. The concern about destructive actions is legitimate. ## INTRODUCTION: THE STATE OF AGENTIC ENGINEERING [0:12](https://youtu.be/l5zgfjXs6gQ?t=12) Welcome to this webinar about agentic engineering — context, guardrails, and creativity. I’m Tomas, product solutions lead at Port, with a background in DevSecOps and prior experience as a solutions architect at GitLab helping organizations build DevSecOps platforms. I’m based in Melbourne. Joining me is Zach, from solutions engineering at Port for APJ, based in Sydney, with a DevOps background. Before we dive in, we wanted to learn the current state of agentic engineering in your organizations. We asked one question: when an AI agent takes action in your engineering workflow today, what is your biggest concern? The results were fairly balanced, but we had a clear winner: “there aren’t enough guardrails to prevent destructive actions.” A close second was “we don’t have AI agents in our workflow yet.” Hopefully, after this session, you’ll have a clearer picture of how to build agentic workflows with the guardrails you need. The concern about destructive actions is legitimate. Recent incidents — such as Amazon accidentally deleting part of a codebase through an AI agent — show that guardrails to prevent destructive actions are the most pressing issue in the industry today. ## THE PROBLEM: AGENTIC CHAOS [4:03](https://youtu.be/l5zgfjXs6gQ?t=243) Even if you take agents out of the equation, the chaos and sprawl of tooling and documentation rings true — especially in 2026. Over the last ten to fifteen years, we’ve tried to solve these issues through DevOps, SRE, and platform engineering, all aiming to simplify and give people an easier platform to interact with. Now we’re adding AI agents on top of that, and the complexity keeps growing. When you look at why the complexity exists and what the key challenges are in getting an agent into a workflow — let alone into production — four points stand out: - Lack of visibility into what agents are doing. - Lack of human oversight and human control. - Duplication of work between engineers and agents. - No real guardrails: how do you wrap guardrails around an AI agent and keep it on the golden path, the happy path toward the goal you’re trying to achieve? In the DevSecOps space, I used to see this pattern constantly. Every team was bringing agents into the organization in very different ways, and there was no centralized place where you could see what agents existed or how they were being used. ## USE CASES UNLOCKED WHEN YOU SOLVE AGENTIC CHAOS [5:47](https://youtu.be/l5zgfjXs6gQ?t=347) If we solve this agentic chaos and gain real control, the landscape opens up. We’re seeing many use cases accelerate: auto incident resolution, self-healing incidents, autonomous ticket delivery, security remediation, compliance checks, and more. Customers we work with are starting to look at full end-to-end implementations. What does an end-to-end agentic workflow really look like when agents do the bulk of the work? For example: taking a feature request and pushing it through to production, or taking an incident and doing all the triage, remediation, and postmortem through one continuous flow. Customers are getting there and having success with it. To make these workflows trustworthy, a few things are essential: - **Context**: the agent is not just a chatbot querying data. It understands what a service is, what constitutes a service, who owns it, and how it connects to the rest of the system. - **Guardrails and RBAC**: the agent can only deploy to a dev environment, or can only take certain actions, depending on clearly defined permissions. - **Human oversight**: the agent is not a black box of inputs and outputs. A human can see and review how it arrived at a decision. ## WHAT CONTEXT MEANS FOR AN AI AGENT [8:53](https://youtu.be/l5zgfjXs6gQ?t=533) When you feed something to an AI agent and say “I want to build X, Y and Z,” it has zero context about your architecture, your language stack, your tool choices (Snyk versus Wiz, for example). At Port, when we talk about a context graph, we mean all the data an engineer would expect to have when building something — services, how they are built, repositories, pull requests, pipelines, and how they relate to each other. Better and more accurate context produces better AI responses. Context is what transforms a generic AI into something useful for your specific environment. ## ADDRESSING AGENTIC CHAOS: THE CENTRAL AGENT REGISTRY [11:44](https://youtu.be/l5zgfjXs6gQ?t=704) Before building an agentic workflow, the first question is: where do I store and control my agents? You need a central repository for the tools and agents your workflows rely on. Whether an agent is built by your team or adopted from elsewhere, you want to register it, share it across teams, and track it. Examples of agents teams commonly share: - A task manager that translates Jira tickets. - An agent that advises on work items. - A triage agent for incidents. By tracking and centralizing these, you can see: - Where the agent comes from. - What tools it can use (its guardrails). - What prompt it runs. - An audit trail of what it has done. A skills registry sits alongside this. As you give AI agents the ability to do very specific things, you need a central place to save valuable prompts and skills — not scattered in someone’s local repository. Teams consume the skills that represent best practice. Everyone can refine on top of them and create specialized agents. Think of this like a Docker registry, or centralized CI pipelines: the platform team centralizes and provides them for consumption by other teams. Avoid rework. Consume what has already been built and proven. ## WORKFLOW ONE: AUTONOMOUS TICKET RESOLUTION [15:13](https://youtu.be/l5zgfjXs6gQ?t=913) The first workflow takes a work item — a bug, a feature — and pushes it through an end-to-end flow: product planning, PRD generation, development, code and security review, and deployment. It can be triggered manually or automatically when a work item arrives. Example: “Add wish list to my cart.” I select the work item and start the process. The workflow begins by fetching the work item details — not just the description, but all the context from the graph. Services involved, where this would deploy, which teams own it (GitHub teams or Port teams), repositories, pull requests, and pipelines. Solid inputs produce solid outputs. With this context, an AI agent generates the PRD. As a human, I can review the plan, see the problem statement, the success criteria, and what is out of scope. I have three options: approve, iterate and add more context, or reject. This is the human oversight layer and part of the guardrail system. Once approved, the workflow moves to develop and review. Scorecards inside Port serve as benchmarks and guardrails: is the ticket ready? Is the plan approved? Has the tech spec been generated? What is the blast radius? **Question from the audience**: “What happens if the ticket is poorly written? Will the agent ask for more information, or will it try to resolve anyway and make assumptions?” To a certain degree, the agent will do what AI does — which is why human oversight is important. The goal is to avoid hallucination: with a proper context graph, the agent won’t invent that you use a three-tier web application when in reality you run microservices on Kubernetes. The context graph shows dependencies, related services (for example, the authorization service connected to the currency service), and provides a much better knowledge base for the agent to work from. At each phase, context is added, and humans can iterate. Agents only access the blueprints and data they are configured for. The work item agent needs access to the work item and relevant services, but not to security information, unless explicitly granted. Targeted access applies to tools, options, skills, and automations — such as “deploy to production” actions — all guided by configuration. Beyond automation speed, the main value of doing this inside a single platform is: - **Context graph** feeding all agents with environment-specific knowledge. - **Guardrails** via scorecards that check whether the workflow is actually achieving its goal. - **Human in the loop** at every phase, applying experience to validate AI output. - **A single control plane** where AI and humans collaborate on the same datasets. You aren’t jumping between Jira, an agent somewhere else, and another tool. The data, context, and knowledge base live in one place. Workflows are fully configurable. The steps shown (fetch work item, generate PRD, develop, review) are a high-level template. You can rename stages, add stages, or reshape the workflow to fit your organization. There is also intelligent routing: rules determine whether an item goes to an AI agent or a human. For a non-mission-critical, customer-facing wish list feature with low blast radius, an agent is suitable. For high-risk changes, a human handles it. ## WORKFLOW TWO: SELF-HEALING INCIDENTS [27:48](https://youtu.be/l5zgfjXs6gQ?t=1668) This is the exciting one for anyone who has worked as a cloud engineer or DevOps practitioner. Getting up at 2 a.m. to handle a P2 incident while half asleep is the dream use case for AI: let it do the triage, investigation, and most of the remediation work. Customers are letting AI resolve incidents end-to-end — from alert to postmortem — in controlled settings, including some financial institutions. The flow looks like this: - Receive an alert. - Triage. - Investigate. - Remediate. - Resolve. - Generate postmortem / root cause analysis. Each step is time-consuming for humans. AI provides the leg up. Example: a “checkout payment failure” incident. The workflow fetches incident details, pulls all related entities from the context graph — impacted services, recent deployments, related microservices — and presents a triage. A real case: a Kubernetes cluster outage that affected 20 microservices with 20 different owners. The context graph lets you instantly identify the right owners and bring them into the same room. The initial triage shows a high service error, business impact, and upstream/downstream services affected. If the triage looks right, you move to investigate. Port AI uses skills from the registry (“investigating incidents”) combined with MCP servers to pull data from external systems: CloudWatch, Datadog, and others. The AI loads tools progressively, giving it an even more complete picture. **Question from the audience**: “Can we mandate standardized governance and compliance checks within the project life cycle for all full-stack projects?” Yes. Using scorecarding, we benchmark against defined standards: a pull request should have a code scan, code coverage greater than 85%, all unit tests passing. You define the benchmarks and the system enforces them as guardrails — on humans and agents alike. **Question**: “Are we triggering the workflow for the incident or is the agent listening to the alerts?” In the demo, we triggered it manually (to avoid non-stop AI triggering). In production, as soon as you receive an incident, the workflow can run the triage automatically and give you the first summary. Routing rules then decide if it needs a human or continues on the AI path. A useful pattern is using AI for initial triage of any ticket — is this actually an incident, or not? Remediation and resolution close the loop. Port combines agent assessments with tools for rolling back deployments, syncing an Argo application, or executing scripted recovery. Finally, the most tedious part — root cause analysis — is handled by a postmortem AI that pulls data from the full incident lifecycle: initial alert, triage, investigation, remediation. This keeps ITSM and problem-management work up to date without replacing humans. AI isn’t replacing humans — it is speeding up work that takes ages, especially at 2 a.m. The RCA angle is particularly valuable: out of 100 incidents, perhaps 90 share the same root cause. Because that data lives in Port, AI agents can make recommendations and remediations consistent across related incidents. For low-priority P4 incidents, Port can recognize that a similar issue has been seen before and recommend the previous remediation — not just as an ITSM lookup, but enriched with the full context of the affected service and trends. ## MEASURING ROI: HOW DO YOU KNOW IT’S WORKING? [29:01](https://youtu.be/l5zgfjXs6gQ?t=1741) Different personas care about different metrics. Some examples: - **Tickets resolved autonomously** — features delivered by autonomous ticket resolution. In one example, 64% adoption signaled meaningful usage. - **Time saved** — especially valuable for leadership. For example, 17,000 hours saved by autonomous ticket resolution, which multiplied by loaded engineering cost becomes a large financial number. - **Incidents resolved by self-healing agents** and hours saved there. One critical recommendation: define a baseline before introducing agents. How long does it take today to deliver a ticket to production — from the moment the Jira is opened to the moment it is resolved? Measure what you currently have, then compare after the AI agents are introduced. The delta is your ROI. ## IS THE AGENT DOING A GOOD JOB? [41:04](https://youtu.be/l5zgfjXs6gQ?t=2464) Numbers can go up without really meaning anything. Better signals: - **Autonomous ticket resolution**: the number of executed ATR workflows should grow along with features delivered, and the backlog — especially low-priority technical debt tickets — should shrink. - **Self-healing incidents**: the total number of incidents should decrease as self-healing usage grows. Why? Because the AI agents help across the full lifecycle — understanding who is involved, how to remediate based on past RCAs, and applying fixes before incidents recur. ## THE END-TO-END FEEDBACK LOOP [45:31](https://youtu.be/l5zgfjXs6gQ?t=2731) This is the piece I love most in Port: all data flows into a context graph that the AI agents can rely on as a trusted source. Metrics and ROI are surfaced, but the same platform can trigger workflows based on thresholds. Example: if the PR throughput or lead time for a specific team starts dropping, that condition can trigger an agentic workflow automatically. The improvements loop back into the platform, and you can see them reflected in the metrics. Data in, workflows out, improvement visible, loop repeats. ## EXTERNAL DATA: MCP CONNECTORS [46:39](https://youtu.be/l5zgfjXs6gQ?t=2799) A common customer ask: “We ingest a lot into Port, but we have other unstructured data — maybe in Notion, maybe in Slack. Can agents use that too?” Yes. Beyond traditional integrations (AWS, GCP, GitHub, Bitbucket, Jira, ADO), Port supports MCP servers. You can enable MCP for Atlassian, Notion, Datadog, CloudWatch, and others. Agents can then query multiple data sources when investigating an incident or triaging a ticket. Port remains the control plane and context graph, while MCP connectors give agents the ability to enrich workflows with context from external tools — like Slack conversations during an incident. ## ACCESSING PORT DATA FROM OUTSIDE [49:12](https://youtu.be/l5zgfjXs6gQ?t=2952) The reverse is also supported. Port exposes its own MCP server. From a tool like Claude, you can connect the Port MCP and query blueprints, services, workflows, and trigger automations. This is especially useful for ROI dashboards and ad hoc questions — for example, asking about relationships between services and users, or understanding adoption of agentic workflows without leaving your AI tool. The webinar theme is context, guardrails, and creativity. Creativity is a big part of this: with the context graph, there are plenty of great use cases and automations waiting to be built. You can show value to different teams, identify gaps, and discover what is and isn’t working. ## HOW TO GET AGENTIC ENGINEERING RIGHT: SUMMARY [51:20](https://youtu.be/l5zgfjXs6gQ?t=3080) Three workflows were demonstrated: autonomous ticket resolution, self-healing incidents, and measuring the impact through engineering intelligence. Getting agentic engineering right comes down to trust — trust in the AI, and trust in the humans to do what they need to do. The building blocks: - A central place for AI and humans to collaborate on the same dataset. - Context injected into the AI agents. - Guardrails and human-in-the-loop oversight for governance. - Reusable skills, prompts, and agents shared across teams. Reuse drives control, trust, and a higher ROI because teams deploy agentic workflows with confidence and push them toward a true end-to-end experience. ## CALL TO ACTION AND AUDIENCE Q&A [52:30](https://youtu.be/l5zgfjXs6gQ?t=3150) You can build this yourself. Create an environment in Port, start ingesting your data, and follow the many guides — whether for security, engineering intelligence, or autonomous ticket resolution. Creativity matters: build something cool for your own use case. Reach out if you need a mapping session to translate your engineering reality into agentic workflows. **Final question — from Alvin**: “In a distributed environment involving API, backend, system of record — does the platform automatically generate and propagate a correlation ID, end-to-end ID, or source/destination to assist with triage?” Port is not trying to replace your log systems. We pull information out of them to allow correlation. For full end-to-end tracing — analyzing logs, following requests across services — external MCP connectors become important. Port provides the context (what the service is, where the pull request lives, when the last deployment occurred) and then agents can call out to Datadog, New Relic, and others to pull end-to-end traces. As you saw in the incident flow, the AI agent uses skills that call these additional tools as part of the workflow, enriching the investigation with data from every relevant source.