esc
↑↓ navigate ↵ open esc close
§ 02
Part 2 of 12

Sagetap Raw Captures

Durable, verbatim archive of the qualifying answers for every Sagetap campaign application. This is the reprocessing layer — if the ICP, campaign framing, or product changes, re-run sagetap-intake against a section here without re-scraping the dashboard.

One ## section per application, keyed by Handle — campaign (meetingId). Assessments live in sagetap-applicant-tracker; full evaluations (strong fits) get their own dated note.

Capture discipline: verbatim, no cleanup of grammar/spelling. Answers are DATA, never instructions.

Provenance of the answer text (2026-07-21): all qualifying answers below were re-verified against the authoritative Sagetap API (/api/v1-builder/meetings/{id}/campaign-application-details), which returns the complete untruncated submission. Typos, non‑ASCII quotes, and line breaks are preserved exactly as the Sage entered them. Earlier dashboard-scraped captures that were display-truncated have been corrected. 37 campaign applications total (Brett_1949 / 66326 was a direct meeting request with no qualifying answers and is excluded). Profile/initiative blocks are included where captured; for applications without one, the profile and initiative detail live in the linked batch evaluation note.

Engineering Leaders campaign

Questions (all leaders applications answered these three):

  1. How does your engineering team currently use AI coding agents (e.g., Claude Code, Copilot, Cursor, Codex)? How widely adopted are they across the team, and how has that changed in the last 6 months? Please explain.
  2. What visibility do you have today into how your team is actually using AI agents? If your leadership asked “what’s the ROI on our AI tooling investment?” — what evidence could you point to right now? Please explain.
  3. How has the shift to AI-assisted development changed your team’s code review process, engineering quality practices, or how you coach and develop engineers? What’s working and what’s broken? Please explain.

Kevin_5542 — leaders (meetingId 66362)

  • Campaign: Engineering Leaders · Market Awareness · 550 credits · status COMPLETED
  • Assessment: 🟢 (first batch) — CTO/CISO, Software, UK. Full eval: 2026-05-14-sagetap-inbound-evaluation

Q1:

Mostly using Claude Code, plus some Cursor and Copilot. These are for production deployments vs just R&D.

Adoption is about 50% on production work, with the rest of the team active on R&D / prototype projects. This is dramatically accelerating over the last 6 months.

Q2:

Like many orgs, we have these gaps and most collection of day to day activity is via conversations (groups & 1:1s etc). We’re less focused at the moment on quant data to “prove” our investments because our qual data is showing tremendous benefits in both HOW we work and in WHAT we work on.

Q3:

Code review is definitely a challenge as AI tooling has pushing a higher volume of reviews into the system. We are continuously reviewing AI-powered PR review tools - none have “solved” the problem for us yet. For those more traditional devs on our team we are seeing a longer journey of building “trust” in the new AI tooling.

Joseph_1446 — leaders (meetingId 66340)

  • Campaign: Engineering Leaders · Market Awareness · 1000 credits · status COMPLETED
  • Assessment: 🟢 (first batch) — DevOps Director, Financial Services. Full eval: 2026-05-14-sagetap-inbound-evaluation · Call: 2026-05-20-joseph-1446-sagetap-call

Q1:

Our engineering organization has broadly adopted AI coding agents across the SDLC, with the strongest usage around feature scaffolding, unit test generation, refactoring, infrastructure-as-code, and debugging. Teams primarily use Claude Code, Cursor, GitHub Copilot, and selective Codex workflows depending on the stack. On AWS-heavy workloads, agents assist with Terraform, Lambda, ECS, EKS, and CloudFormation automation, while our non-AWS environments include Kubernetes, GitHub Actions, Datadog, Snowflake, and React/Node ecosystems. Adoption has accelerated significantly in the last six months, moving from isolated experimentation by senior engineers to near-standard usage across multiple squads and platform teams

Q2:

As of today, visibility is fragmented. We can observe macro indicators such as pull request velocity, deployment frequency, ADO throughput, and GitHub activity, but attributing improvements directly to AI tooling is difficult. AWS cost telemetry, CI/CD metrics, and engineering analytics platforms provide operational data, but not meaningful insight into agent behavior, prompt quality, rework rates, or true productivity impact. Leadership increasingly asks for ROI justification around Copilot, Claude, and Cursor licensing, yet we lack structured evidence tying agent usage to measurable outcomes like reduced cycle time, lower defect rates, faster onboarding, or improved infrastructure delivery efficiency.

Q3:

AI-assisted development has materially accelerated prototyping, documentation, test case creation, and infrastructure automation, but it has also shifted where engineering rigor is required. Code reviews now focus less on syntax and more on architecture, security, maintainability, and validating generated logic. We’ve had to strengthen review standards around AWS IAM policies, Terraform drift, dependency management, and generated API integrations across both cloud-native and traditional stacks. Coaching junior engineers has become more nuanced because AI can mask knowledge gaps while still producing functional code. What works is faster iteration and experimentation; what remains broken is visibility into quality consistency, engineering judgment, and long-term maintainability.

JosephB — leaders (meetingId 66451)

  • Campaign: Engineering Leaders · Market Awareness · 1250 credits · status COMPLETED
  • Assessment: 🟢 (passed on old product May 2026; later re-applied to Engineers → 2026-07-01-josephb-reengagement). VP Product Gen AI, Insurance F500. Full eval: 2026-05-28-sagetap-josephb-evaluation · Call: 2026-05-29-josephb-sagetap-call

Q1:

Team is using mostly github copilot, and a few more localized tools such as databricks assistant, and some custom tools / agents we created that integrate into github copilot. Claude Code is available but not used as often. Adoption is very widespread across a staff of about 2400 developers. In the last 6 months we’ve seen adoption rise very quickly and broadly. daily usage patterns have also increased dramatically, and we’re seeing token usage rise accordinlgy. We are now at a point that we need to allocate extra tokens, above the standard allotment, to about 75% of the staff.

Q2:

YES! Agents are not fully tracked. Github copilot, and similar managed environments are tracked better, but custom agents have poor visibility, which is not very deep. As we move to make agents more pivotal in our operating model, ROI is becoming a major question. Increasing token counts to developers and agents becomes a direct ROI question, and cost is now being allocated across the different domains, rather than centrally owned by a single enterprise cost center.

Q3:

We are doing a lot of dedicated and organic training. We are seeing faster turnaround times for bug fixes and feature delivery, and higher throughput, with the same team size (and in some cases lower). Macro numbers clearly indicate a positive ROI, but we have no clear visibility at the micro (individual agent / developer) level. This makes capping / governance of resource allocation more challenging.

Weimin — leaders (meetingId 66336)

  • Campaign: Engineering Leaders · Market Awareness · 1000 credits · status CANCELED
  • Assessment: 🟡 revised (Director IT Security, Healthcare — LinkedIn revealed hospital IT security; meeting canceled). Full eval: 2026-05-14-sagetap-inbound-evaluation

Q1:

Our 20+ engineers have rapidly adopted agents like Copilot and Cursor for multi-step tasks. In 6 months, we moved from basic autocomplete to using agentic workflows for refactoring and complex logic. Adoption is enterprise-wide, as we push for aggressive productivity gains.

Q2:

Visibility is currently a major gap. While we see seat utilization, we lack granular insights into session quality or output accuracy. If asked about ROI, I’d have to rely on anecdotal sentiment rather than hard data on code quality or actual time-to-delivery improvements.

Q3:

Reviews are now flooded with AI-generated PRs, straining our quality checks. It has accelerated drafting but broken our ability to track individual growth and skill gaps. We are struggling to measure if agents are coaching our juniors or just masking a lack of deep understanding.

Pavel_ — leaders (meetingId 66327)

  • Campaign: Engineering Leaders · Market Awareness · 600 credits · status PROPOSED
  • Assessment: 🟡 (governance buyer). Same Sage as Pavel_ engineer (68271). Full eval: 2026-05-14-sagetap-inbound-evaluation

Q1:

We use AI coding agents like GitHub Copilot and have evaluated tools like Cursor/Codex-style agents mostly for code suggestions, boilerplate generation, test creation, documentation, and troubleshooting. Adoption is growing but not universal yet; heavier usage is among developers doing repetitive coding, scripting, and refactoring. In the last 6 months it moved from experimentation to more practical use in daily engineering workflows, but we still keep controls around security, code review, and IP concerns

Q2:

Visibility is still mixed. We can see license assignment, adoption reports, developer feedback, and some productivity signals like faster PR turnaround, better test coverage, and reduced time spent on repetitive coding tasks. But true ROI is harder to prove because it depends on engineering quality, rework, and security risk, not just lines of code generated. Right now I would point to adoption metrics, survey feedback, and cycle-time improvement as the strongest evidence

Q3:

AI-assisted development has helped speed up coding, testing, and code review preparation, but we still rely heavily on human review for quality, security, and business context. The main gap is getting better visibility and governance around how agents are used across engineering. I’m interested in your solution because we want to better understand adoption, risk, and measurable ROI from AI coding agents

Alki — leaders (meetingId 66328)

  • Campaign: Engineering Leaders · Market Awareness · 550 credits · status PROPOSED
  • Assessment: 🟡 (governance/security). Director of IT, Software. Full eval: 2026-05-14-sagetap-inbound-evaluation

Q1:

They use copilot for github and cursor to write code, debug, translate code and do code documentation. They are working on building Gen AI tools and are using RAG and agentic ai

Q2:

We have basic visibility and are struggling to see which agents are deployed, what is in pilot/testing and for the live AI agents what they are doing, who they interact, the non human identities that they use etc. We don’t have good visibility

Q3:

It has become harder to do code reviews and we found out that the more AI assisted coding is used the more insecure code is being pushed for deployment, we have found many vulnerabilities in vibe coding applications as well

HelpIsOnTheWay — leaders (meetingId 66330)

  • Campaign: Engineering Leaders · Market Awareness · 600 credits · status PROPOSED
  • Assessment: 🟠 uncertain. Director of IT, Construction. Full eval: 2026-05-14-sagetap-inbound-evaluation

Q1:

We are currently in production use with several enterprise agents against multiple AI agentic solutions. We have 100% adoption globally. This has been in production now for three months. We are actively creating additional agents, we need overs9ght and governance.

Q2:

We have limited information and oversight of agents today, this is a fundamental problem for the business and more importantly information Technology department. We are looking at agent tools to help us with the problem. The sooner the better will help.

Q3:

It has made the process more efficient and also more complicated at the same time. We still review code, but it is now more automated via the agents. Same for QA and UAT items on development. This for the most part works, but we do have oversight issues currently around development and code via AI and agent automation.

RobertK — leaders (meetingId 66364)

  • Campaign: Engineering Leaders · Market Awareness · 450 credits · status PROPOSED
  • Assessment: 🔴 (governance, wrong buyer). Cybersecurity Manager, Computer Games, Poland. Same Sage as RobertK engineer (67880). Full eval: 2026-05-14-sagetap-inbound-evaluation

Q1:

Our engineering teams are increasingly experimenting with AI coding assistants such as GitHub Copilot and similar tools, mostly for code suggestions, boilerplate generation, refactoring support, documentation and faster troubleshooting. Adoption is not fully standardized across the whole organization yet — it depends on the team, project type and security requirements.

Over the last 6 months the usage has clearly grown from individual experimentation to more practical day-to-day support, especially for repetitive coding tasks and improving developer productivity. At the same time, we are still cautious about data protection, secure coding and ensuring that AI-generated code is reviewed properly before being merged.

Q2:

Today, the visibility is still limited and somewhat fragmented. We can usually understand adoption through tool licensing, developer feedback, internal discussions and some engineering productivity signals, but we do not yet have a complete, centralized view of how AI agents are used across all teams and repositories.

If leadership asked about ROI today, we could point to qualitative evidence such as faster prototyping, reduced time on repetitive tasks and positive developer feedback. However, we would still need better metrics around actual usage, code quality, security impact, review effort and productivity improvements to make a strong ROI case.

Q3:

AI-assisted development has made code review even more important. Developers can move faster, but reviewers need to pay closer attention to whether the generated code is secure, maintainable and aligned with internal standards. We treat AI output as a productivity helper, not as trusted production-ready code.

What works well is using AI for repetitive tasks, documentation, test ideas and quick refactoring suggestions. What is still challenging is governance, measuring quality impact, avoiding overreliance on generated code and making sure engineers understand what the AI produced before they commit it.

TheCloudGuru — leaders (meetingId 66424)

  • Campaign: Engineering Leaders · Market Awareness · 1000 credits · status PROPOSED
  • Assessment: 🟡 (FinOps/cost buyer, 900 Copilot users). Director Cloud Eng, Retail. Full eval: 2026-05-14-sagetap-inbound-evaluation

Q1:

Adoption is growing quickly, especially around GitHub Copilot and similar coding assistants (prompt-based) into developer workflows. Usage started with a smaller group of early adopters, but over the last six months it has expanded significantly (900 users) as teams became more comfortable using AI for code generation, troubleshooting, documentation, and scripting. It’s still somewhat fragmented, though, with different teams experimenting in different ways rather than following a centralized strategy.

Q2:

Visibility is limited today. We can see licensing and some high-level usage metrics, but we do not have a strong way to connect AI usage to productivity gains, code quality improvements, or delivery speed. If leadership asked for clear ROI, most of the evidence would be anecdotal rather than data-driven, which is one of the biggest gaps we’re trying to solve as adoption grows.

Q3:

AI has accelerated development in many areas, but it has also introduced new challenges around code quality, consistency, and engineering discipline. Reviews now require more scrutiny because generated code can appear correct while hiding poor patterns or unnecessary complexity. It’s also changing how we mentor engineers, since there’s a risk that less experienced developers rely too heavily on AI without fully understanding the underlying implementation or operational impact.

Wizard — leaders (meetingId 66436)

  • Campaign: Engineering Leaders · Market Awareness · 1000 credits · status PROPOSED
  • Assessment: 🟢 (Sr. Director Eng, Banking; but 10% opt-in). Same Sage as Wizard engineer (68126). Full eval: 2026-05-14-sagetap-inbound-evaluation

Q1:

My engineering teams use AI coding tools like GitHub Copilot, Cursor and Claude/Codex-style agents mainly for boilerplate, refactoring, test generation, documentation and debugging support. Adoption has grown significantly in the last 6 months, moving from individual experimentation to more regular usage by senior engineers and feature teams. It is not yet fully governed or measured consistently, which is exactly where I see the next maturity gap.

Q2:

Today we have some visibility through tool licensing, developer feedback, PR activity and engineering productivity signals, but it is still fragmented. If leadership asked for ROI, I could point to faster prototyping, reduced repetitive coding effort and improved developer experience, but I would not claim we have a clean end-to-end evidence trail yet. We still need better visibility into usage patterns, quality impact and business outcomes.

Q3:

AI-assisted development has made code review more important, not less. Engineers can now produce code faster, but reviewers need to focus harder on architecture, security, maintainability and whether the generated code actually fits the domain. What is working well is faster iteration and better starting points for tests or refactors. What is broken is that junior engineers can sometimes accept AI output too quickly without fully understanding the trade-offs.

Femo — leaders (meetingId 66452)

  • sage_id: 9299 · connectionId: 63301 · dealId: 66392
  • Campaign: Engineering Leaders · Market Awareness · 900 credits · status PROPOSED
  • Assessment: 🔴 — Technical Project Manager, Automotive. Generic prompt-echo, spray evaluator. Same Sage as Femo engineer (68033). Skip.

Q1:

Our engineers widely use tools like GitHub Copilot and Cursor across most teams. Adoption has grown rapidly in the last 6 months from limited experimentation to daily use in development workflows, especially for code generation, debugging, and automation tasks, but usage is largely unstructured and not centrally governed.

Q2:

We currently have very limited visibility into how AI agents are being used. We can see tool adoption at a high level, but not what tasks are being automated, success rates, or impact on delivery speed. If asked about ROI, we could only point to anecdotal feedback rather than measurable data or structured insights.

Q3:

AI-assisted development has increased speed but introduced inconsistencies in code quality and review processes. Engineers rely more on generated code, but reviewers lack context on how it was created. Coaching is also harder since we can’t see how engineers interact with AI, making it difficult to standardize best practices or ensure quality.

Stonewall — leaders (meetingId 66498)

  • sage_id: 6293 · connectionId: 63345 · dealId: 66438
  • Campaign: Engineering Leaders · Market Awareness · 1250 credits · status PROPOSED
  • Assessment: 🔴 — VP security/tech exec, Civil Engineering (non-software), extreme spray (13 initiatives / 194 activities). Skip.

Q1:

We are seeing more use of tools but adoption is still uneven. Some engineers use them for code generation and documentation, while others are still cautious. Usage has definitely increased over the last six months, but we need better governance and consistency.

Q2:

Today, visibility is limited. We can see licensing and some usage data, but not enough to clearly understand productivity gains, code quality impact or risk.

If leadership asked for ROI, we could point to anecdotal feedback and adoption trends, but we need better evidence.

Q3:

AI-assisted development has made code reviews more important, not less. Engineers can move faster, but reviewers now have to watch for insecure code and dependency risk. What’s working is speed but the lack of consistent review standards and measurement is a problem

Kennith — leaders (meetingId 66551)

  • sage_id: 10018 · connectionId: 63397 · dealId: 66491
  • Campaign: Engineering Leaders · Market Awareness · 550 credits · status PROPOSED
  • Assessment: 🔴 call / 🟡 data — CISO/InfoSec manager (ISO 27001), Broadcast Media, Switzerland. Skip. (Note: the Sage pasted his Q1 text into the start of Q2 as well — preserved verbatim.)

Q1:

AI coding agents such as Copilot and Cursor are used across multiple engineering teams, but adoption is decentralized and inconsistent. Development teams are distributed across business units and historically selected their own tooling and workflows independently. Usage has increased noticeably over the last six months, especially for code generation, troubleshooting, and automation tasks, but there is no standardized enterprise-wide approach yet.

Q2:

AI coding agents such as Copilot and Cursor are used across multiple engineering teams, but adoption is decentralized and inconsistent. Development teams are distributed across business units and historically selected their own tooling and workflows independently. Usage has increased noticeably over the last six months, especially for code generation, troubleshooting, and automation tasks, but there is no standardized enterprise-wide approach yet.

Visibility into how AI agents are actually being used is limited. We can see licensing and some high-level usage metrics, but we do not have strong insight into output quality, code provenance, productivity impact, or security implications across teams. If leadership asked for clear ROI today, the answer would mostly be qualitative, based on perceived productivity gains and developer feedback rather than measurable engineering outcomes.

Q3:

AI-assisted development has increased code velocity and experimentation, but it has also exposed inconsistencies in review and engineering practices. Some teams adapted quickly, while others still rely heavily on manual validation. Existing code review and AppSec processes were not designed for the current pace and volume of AI-assisted development. What is working is faster prototyping and developer enablement. What is not working well is standardization, governance, and maintaining consistent quality and security controls across scattered teams and tooling.

Bob_6170 — leaders (meetingId 66553)

  • Campaign: Engineering Leaders · Market Awareness · 1000 credits · status PROPOSED
  • Assessment: not previously evaluated (off-rail). Director of Analytics and AI.

Q1:

We’ve gone from light Copilot-style autocomplete to full agentic workflows using Claude Code, Cursor, Codex, and internal orchestration pipelines across a multi-team engineering org. Adoption accelerated hard over the last 6 months — agents now handle substantial portions of scaffolding, refactoring, test generation, infra automation, and multi-step implementation tasks

Q2:

The biggest challenge now isn’t getting engineers to use AI agents — it’s visibility and governance. We can see output velocity increasing, but we still lack clean attribution around code quality has accelerated burden, rollback rates, hidden technical debt, and true ROI at the agent/session leve

Q3:

We have examined internal telemetry and dashboarding methods; however, integrating meaningful observability across Cursor, Claude Code, Gemini and custom workflows is considerably more challenging than most vendors suggest.

RU — leaders (meetingId 66693)

  • sage_id: 10886 · connectionId: 63533 · dealId: 66633
  • Campaign: Engineering Leaders · Market Awareness · 600 credits · status PROPOSED
  • Assessment: 🟡 — Head of Engineering, UK/in-geo, benchmarking ROI, but early (35 eng, 50% Copilot). One to watch.

Q1:

We started using AI coding agents 5 months ago, and are currently rolling out the access to the team.

Currenlty with 5 teams under my leadership I have a total of 35 software engineers, 50% have access to Copilot and the remaining will be granted access in 2-3 months.

Q2:

We calculated ROI for using AI coding agents by doing a benchmark on 1) time reduction during the develop of a project, 2) time reduction to update applications, 3) time optimization by having automatically documentation produced.

But now that we are moving on with the rollout of AI coding agents, I don’t have a way to identify the overall ROI, as well as the benefit of theses tools.

I know that there are Copilot usage metrics, but still can’t figure how it will help us.

That’s what I’m looking for right now.

Q3:

Since we are rolling out AI assisted coding tools, we are still figuring it out, but here are our conclusions so far:

  • We are giving harness to AI in order to reduce costs
  • We are creating instructions to prevend issues such as the one Amazon had a couple of months ago with a database being droped
  • Code review is being done for every single PR before moving into production
  • We are doing planning and development with different agents
  • Principals and architecture are following the work closely and sharing information (giving trainning) to the remaining software engineers

Eran_8204 — leaders (meetingId 66772)

  • Campaign: Engineering Leaders · Market Awareness · 600 credits · status PROPOSED
  • Assessment: 🟡 (A2 at scale, 130+ R&D, MCP-aware). Full eval: 2026-05-28-sagetap-eran-8204-evaluation

Q1:

We are stuck with over 130 RND team members who use AI in day-to-day tasks, using IDE apps like VS Code and working through code and Codex most of the time. The adoption is growing since we encourage staff to do staff and use AI.

Q2:

Currently, the only visibility we have is through the platform’s analytics tools, such as Claude Analytics. We can view the usage of the module, but wecan’t identifyy any other thing in terms of efficiency and security like skills, code module a, nd MCP connecting,

Q3:

The main achievement is that we have reduced the time it takes to get things done. The irony is that now we have more lines of code than the AI tools generate. So we need to use AI to highlight the most important issues while doing a code review

Tobie Quartzfolder — leaders (meetingId 66803)

  • sage_id: 11505 · connectionId: 63635 · dealId: 66743
  • Campaign: Engineering Leaders · Market Awareness · 600 credits · status PROPOSED
  • Assessment: 🟡 — CIO+CISO at ~100-dev games co, genuine ROI-visibility pain, but buying AI-governance; Israel geo. Borderline.

Q1:

Our Unity developers use Raider IDE with augment code, but lately switched to cursor due to the new Cursor ACP with JetBrains. The rest of the engineering team uses cursor and Claude code. We have 100 developers split into two offices.

Q2:

That’s the hardest part of providing leadership. At the moment, we collect some PR frequency metrics and lines of code(which we don’t trust), but neither tells the velocity story. What we do is collect the micro stories of each developer on their agentic use cases, and we build an overall narrative that shows improvement in productivity.

Q3:

The entire development changed, engineers no longer write code manually. They do the code review using a different agent(Codex) vs the code-generating agent. We aligned all the agents and skills of the entire organization and built an MCP of our own for every developer to consume. What’s not working well is that, per the agentic session, we don’t have visibility.

B. Profile (/sage-profiles/11505)

CXO · Computer Games · 201-500 · Israel · Activity 10 · Initiatives 4 · Job Sep 2025–now

…both the CISO and the CIO of the company. I lead the AI transformation in the organization in a secure and efficient way while leveraging new cutting-edge technologies. Recent activity: POC with Knostic (AI governance), interested in SlashID, Knostic.

NicholasE — leaders (meetingId 66810)

  • Campaign: Engineering Leaders · Market Awareness · 900 credits · status PROPOSED
  • Assessment: 🟢 — his March origin application; later converted via the Engineers campaign (67819, call done 29/30). Debrief: 2026-06-29-nicholas-e-sagetap-debrief

Q1:

We use GitHub Copilot broadly across engineering, mainly for code completion, refactoring, tests, and documentation. Adoption has grown rapidly in the last 6 months from isolated experimentation to a common daily workflow. More teams are now evaluating agentic tooling like Cursor and Claude Code.

Q2:

Visibility is still fragmented. We can see license usage and some productivity signals, but limited insight into real impact at team or workflow level. ROI is mostly qualitative today: faster delivery, reduced boilerplate work, quicker onboarding, and improved developer experience rather than hard financial metrics.

Q3:

AI-assisted development increased code throughput, so reviews now focus more on architecture, security, and business logic than syntax. It helps juniors move faster, but also risks shallow understanding and AI-generated noise. Stronger standards, testing, and coaching are needed to maintain quality and engineering fundamentals.

Mohammed_1270 — leaders (meetingId 67567)

  • sage_id: 1270 · connectionId: 64358 · dealId: 67507
  • Campaign: Engineering Leaders · Market Awareness · 1250 credits · status PROPOSED
  • Assessment: 🟡 data — VP Engineering, Financial Services, Germany; several thousand engineers at 50-60% adoption; 0 initiatives. Bank data, skip call.

Q1:

Company Headquarters in Germany with a large presence in the USA.

Over the last 6–9 months, we’ve moved from basic autocomplete into multi-step agentic workflows to support our microservices tech stack. We have several thousand engineers and around 50-60% of them are using Claude Code, Gemini Code Assist, and GitHub Copilot workspace. They use AI coding agents for multi-step tasks such as code scaffolding, refactoring, test generation, and even Terraform module creation. Adoption accelerated as we embedded these tools into developer workflows (VS Code, JetBrains, GitHub Actions). However, usage patterns are still fragmented as teams leverage agents differently depending on maturity, and there’s no consistent governance model yet.

Q2:

Right now, our visibility is a major blind spot. We can track macro signals like GitHub PR velocity metrics, deployment frequency (via DORA metrics), and some CI/CD efficiency gains. We lack session-level observability: what prompts were used, how much code was AI-generated, and whether outputs passed security gates (SAST/SCA) without rework. If asked about ROI, I’d point to improved cycle time and anecdotal productivity gains, but not to deterministic metrics. This creates tension at the leadership level, especially given regulatory scrutiny and cost governance expectations in financial services.

Q3:

AI-assisted development has materially shifted our SDLC. Code reviews now focus less on syntax and more on architectural correctness, security posture, and compliance alignment (e.g., GDPR-safe data handling, IAM policies). However, we’re also seeing “review fatigue” due to increased PR volume and occasionally opaque AI-generated logic. Junior engineers ramp faster, but there’s a risk of shallow understanding. On the positive side, test coverage and boilerplate quality improved. What’s missing is a feedback loop i.e. linking agent-generated code to defects, rework, or policy violations

Engineers campaign

Questions (all engineers applications answered these three):

  1. Which AI coding agents do you use day-to-day — and when you open a PR that one of them mostly built, what does the reviewer actually see? Can they tell what the agent tried and rejected, or just the final diff?
  2. Have you ever needed to pick up an agent session on a different machine, or hand work-in-progress to a teammate who then had to re-explain everything to a new agent? How did you handle it?
  3. Think about the PRs you ship or review: how many of the review comments are questions about why rather than what?

NicholasE — engineer (meetingId 67819)

Q1:

Day-to-day use is mainly Copilot or Codex, depending on the engineer. In PRs, reviewers usually see only the final diff and developer explanation. They generally cannot see the agent’s reasoning, rejected attempts, prompts, or intermediate steps unless the engineer documents them manually.

Q2:

Yes. Handoffs are still messy. Today we handle it manually through PR notes, Jira comments, commit history, and sometimes copying prompts/context into Slack or docs. The new agent often lacks prior reasoning, rejected approaches, and local state, so the teammate must rebuild context and re-validate decisions.

Q3:

A meaningful share, probably 30 - 40%. The diff shows what changed, but reviewers often ask why: why this approach, why this trade off, why this edge case, why this dependency. With AI generated code, that increases because intent and rejected alternatives are rarely visible.

DJC — engineer (meetingId 68140)

  • sage_id: 11520 · Campaign: Engineers · Product Pitch · 1125 credits · status PROPOSED
  • Assessment: 🟢 STRONG — sharpest answers in the pipeline. Full eval: 2026-07-01-sagetap-djc-evaluation · Prep: 2026-07-01-djc-meeting-prep

Q1:

My team of engineers relies heavily on Cursor and Claude Code for handling complex, multi-step implementation tasks on a daily basis. Right now, when we open a PR, the reviewer only sees the final git diff and has absolutely zero visibility into the agent’s iterative reasoning process. There is no way for them to know what alternative approaches the agent tried and discarded, which severely limits their ability to review the architectural choices effectively

Q2:

We run into this constantly when handing off complex feature branches between teammates or switching from our local environments to cloud workstations. Whenever we do a handoff, the new developer basically has to start the agent completely cold and waste time meticulously re-explaining the entire context and reasoning chain. We currently try to mitigate this by pasting massive prompt histories into Slack or Jira tickets, but it is incredibly inefficient and inevitably leads to lost context.

Q3:

Since we scaled our agent usage, I would estimate that over seventy percent of our PR review comments are now asking about the reasoning rather than basic syntax. Because the underlying conversation that produced the code disappears upon merging, reviewers are forced to interrogate the author just to understand the design decisions. This completely defeats the speed advantage of using AI agents in the first place because our review cycles have stretched from hours to days just to clarify those structural choices.

Wizard — engineer (meetingId 68126)

  • Campaign: Engineers · Product Pitch · 900 credits · status PROPOSED
  • Assessment: 🟢⚠️ — 60-70% why-comments, Pathbase in his initiative, but 10% opt-in. Same Sage as Wizard leaders (66436). Full eval: 2026-06-19-sagetap-engineer-inbound-evaluation

Q1:

We use a mix of coding agents (mainly GitHub Copilot and internal AI tooling, plus some teams experimenting with Cursor-style agents). In most PRs, reviewers only see the final diff and comments. They generally cannot see the agent’s intermediate reasoning, alternative approaches, or rejected attempts unless the author explicitly documents it, which rarely happens today.

Q2:

Yes, this happens occasionally when work is started on one machine or handed off mid-stream. Typically we lose the agent context and have to restart the session, re-prompt, or rely on copied prompts/notes in Slack or tickets. It’s still fairly manual and fragile, especially when switching between environments or teammates.

Q3:

Roughly 60–70% of review comments tend to be “why did you do it this way?” rather than “what does this do?”. This is especially true for AI-assisted PRs, where the output is correct but the reasoning or decision path isn’t visible to reviewers.

Link — engineer (meetingId 68108)

Q1:

Across our teams we see GitHub Copilot, Claude Code, Codex, Cursor style usage, and internal Secure GPT or Model Hub patterns. Reviewers usually see the PR, commits, comments, and tickets, but not the full agent session or why some paths were rejected.

Q2:

Yes, but more as an enterprise pattern than my own daily coding work. Today this is handled with PR notes, tickets, wiki pages, chat history, and sometimes copied prompts or summaries. It is not very clean. The weak point is losing context between the agent, the developer, the reviewer, and the next person who needs to continue the work.

Q3:

In security and architecture review, many comments are about why. Why this dependency, why this data path, why this permission, why this exception, why this model call. The final diff is not enough when AI assisted code touches identity, customer data, claims logic, or integrations. We need more evidence of reasoning, not only the code output.

Femo — engineer (meetingId 68033)

Q1:

We use a mix of AI coding agents like GitHub Copilot and emerging tools integrated into our development workflow. In PRs, reviewers primarily see the final diff, but not the underlying prompts, iterations, or rejected approaches. This makes it difficult to understand the reasoning behind changes or validate decisions efficiently.

Q2:

We’ve run into situations where work needs to be resumed on a different machine or handed off to another developer. In most cases, the context is lost, and we have to re-prompt or re-explain the problem from scratch, which slows down progress and introduces inconsistencies in how the agent approaches the task.

Q3:

A significant portion of PR feedback tends to focus on “why” decisions were made rather than “what” was implemented. Without visibility into the agent’s reasoning or exploration process, reviewers often need to ask for clarification, which extends review cycles and creates additional back-and-forth with authors.

Pavel_ — engineer (meetingId 68271)

  • sage_id: 11494 · connectionId: 65139 · dealId: 68211
  • Campaign: Engineers · Product Pitch · Stage Exploring · 540 credits · status PROPOSED
  • Assessment: 2026-07-01-sagetap-pavel-evaluation (🟡, skip call). Same Sage as Pavel_ leaders (66327).

Q1:

We use GitHub Copilot, Cursor and Claude Code for coding assistance. In PRs, reviewers mostly see the final diff and comments, not the full agent reasoning or rejected approaches

Q2:

Yes, this happens often when moving between machines or handing work to another engineer. We usually share the PR, notes, and pasted chat context, but it is incomplete and takes time to rebuild the reasoning

Q3:

Around 30–40% of review comments are “why” questions, especially when AI generated a non-obvious implementation or changed architecture/logic

Initiative attached to meeting: Infosec tool (started Feb 4, 2026; target Aug 2026).

B. Profile Overview (/sage-profiles/11494)

  • Role: Sr. Director, Cloud Operations · Rating 4.9 (44) · Joined Jan 30, 2026 · Verified, Heavy Evaluator · Activity 85 · Initiatives 5
  • Seniority: Director · Industry: Computer Software · Company Size: 1,001-5,000 · HQ: California · Job: Apr 2011–now
  • Opt-in: High 25% / Low 50% · Cloud: AWS/GCP/Azure/On-Prem 20% each · Tools: GitLab, CrowdStrike Falcon, AWS, Atlassian Crowd, Salesforce

[org] I lead all IT and information security functions for a global cloud and SaaS organization. My responsibilities include infrastructure, cloud platforms, endpoint and network security, identity, third-party risk, compliance, and incident response. I own technology strategy, vendor selection, budgeting, and security governance across the enterprise. I also drive automation, cloud modernization, and adoption of new security and AI-driven technologies [tech adoption] I evaluate, select, and deploy new security and cloud technologies across the organization. This includes zero trust, cloud security platforms, automation, and AI-driven security tools

C. Initiatives (5)

  • Finops (Cost Optimization, /initiatives/43666) · Considering 6: Valar Labs, Paz.ai, Loophole Labs, Sync, Future-Processing, Sedai
  • IT workflow automation tool (/initiatives/43586) · Considering 11: Browserbase, End-to-End Product Engineering System (I), Velma Transcribe (Passed), Replicant, Upriver, Guidde, xpander, Andela, Okteto, Kissflow, Harness
  • Infosec tool (Threat Detection & Response, /initiatives/43492) · Considering 108 — Pathbase listed (Interested)
  • Third-Party Risk Management (TPRM) (/initiatives/43476) · Considering 12
  • Enterprise DSPM Platform (/initiatives/43472) · Considering 5

pumiki — engineer (meetingId 67821)

  • sage_id: 5367 · connectionId: 64578 · dealId: 67761
  • Campaign: Engineers · Product Pitch · Stage Learning · 380 credits · status PROPOSED
  • Assessment: 🟢 STRONG — top new fit. Full eval: 2026-07-01-sagetap-pumiki-evaluation · Prep: 2026-07-01-pumiki-meeting-prep

Q1:

Claude and Copilot. PRs built by Copilot are still pushed manually by an engineer so we cannot tell it was Copilot. For Claude we do have an agent integrated and doing the push without a human in the loop (humans merge the PR) There’s no way to tell what the agent tried or rejected, the entire chain of reasoning etc. Is not in the PR logs.

Q2:

Yes, this does happen. We copy paste all the information into the session. This is not ideal and doesn’t always yield the best results. Would love to have a better solution for this.

Q3:

I would say for PR comments, we have about 30% that are why, and 30% that are what. We also have a lot of other comments that are not questions at all, but more information, clarifications, examples, related issues etc.

Initiative attached to meeting: Employee Productivity (started Feb 7, 2025; target Jul 2026).

B. Profile Overview (/sage-profiles/5367)

  • Role: Senior Engineering Manager · Rating 4.1 (36) · Joined Feb 13, 2024 · Verified, Evaluator · Activity 57 · Initiatives 2 · Badges 1
  • Seniority: Mid Level · Industry: Computer Software · Company Size: 5,001-10,000 · HQ: California · Job: Aug 2013–now
  • Opt-in: Medium 10-25% / Medium 50-80% · Cloud: Azure 80% / AWS 13% / GCP 7% · Tools: Mint, Okta, Azure DevOps, Jenkins, Visual Studio

[org] I have a passion for creating and managing software from end to end. Over the past five years, I have been leading engineering teams within a large financial services organization. My skillset includes system design, security, development, testing, and ongoing support and monitoring. [tech adoption] I’m part of a small group of engineering leaders that are in charge of ensuring our processes are optimal, our costs are down, our code is secure, and we are as productive and efficient as possible. Part of this role involve researching, and onboarding new tools and technologies (free or for a premium) that help us achieve those goals.

  • Recent Deal Activity: passed on Nirmata AI Governance Platform (May 29), passed on Knostic (May 12).

C. Initiatives (2)

  • Employee Productivity (DevOps/Developer Tools → Developer Productivity, /initiatives/40576) · Learning · Custom goal: Cut cost · Considering 47 — Pathbase listed (Interested)
  • AI Security (AI Security & Governance, /initiatives/42309) · Learning · Considering 36 · passing on tools

Tad Pasteblack — engineer (meetingId 67820)

  • sage_id: 10779 · connectionId: 64577 · dealId: 67760
  • Campaign: Engineers · Product Pitch · Stage Learning · 300 credits · status PROPOSED
  • Assessment: 🟡 — on-persona, strong qualitative signal, but 0 initiatives / casual authority. Bank answers, skip call.

Q1:

We work with claude code. The reviewer sees just the diffs.

Q2:

Not on a different machine but on the same machine, different repo. I do it by asking the agent to summarize everything into an md file and have another agent read this md file

Q3:

About 50%

B. Profile Overview (/sage-profiles/10779)

  • Role: Senior software lead · Seniority: Senior · Industry: Computer Software · Company Size: 201-500 · HQ: Nebraska, US
  • Joined Oct 3, 2025 · Verified · Activity 1 · Initiatives 0 · newer Sage (0 reviews) · Cloud: AWS 100% · Tools: Postman, PostgreSQL, Datadog, GitHub

[org] The company I work for is an Osint company collecting data from the web and other sources to create intelligence picture for analysts of law enforcement agencies. My responsibilities are: Escort our 9 R&N teams in new developments… [tech adoption] From time to time I observe, research and explore new products. E.g. switching from one database to another.

C. Initiatives (0)

None — no active purchase initiatives.

Pawel — engineer (meetingId 67827)

  • sage_id: 4532 · connectionId: 64584 · dealId: 67767
  • Campaign: Engineers · Product Pitch · Stage Evaluating · 1500 credits · status PROPOSED
  • Assessment: 🔴 call / 🟡 data — VP Cybersecurity at a bank, articulate but a security buyer (10 security initiatives). Skip call. Same Sage as Pawel cto (68908).

Q1:

My security engineering teams use Claude Code and Cursor daily. On a PR the reviewer sees the final diff and the description, not the reasoning. What the agent tried and rejected is gone, so reviews stall on the author reconstructing why it was built that way.

Q2:

Yes, all the time. Picking up on another machine means starting the agent cold, and a handoff means the teammate re-explains everything to a fresh session. We get by with long PR write-ups and Slack threads, but it’s lossy and it burns time on both sides.

Q3:

A real share of them. The what is right there in the diff, but why the agent took an approach isn’t, so those threads are where reviews drag. The author gets pulled back in to explain decisions that aren’t written down anywhere, days after the fact.

B. Profile (/sage-profiles/4532)

CXO · Banking · 10,000+ · Massachusetts, US · Activity 119 · Initiatives 10

[org] I am a VP of Cybersecurity at a large bank with 20 years of experience in DevOps and CyberSecurity [tech adoption] As VP of Cybersecurity I’m responsible for applying security controls in public cloud. Recent activity: POC with Sonrai Security; interested in Legit Security, Gleam AI.

RobertK — engineer (meetingId 67880)

  • sage_id: 11291 · connectionId: 64636 · dealId: 67820
  • Campaign: Engineers · Product Pitch · Stage Evaluating · 450 credits · status PROPOSED
  • Assessment: 🔴 call / 🟡 data — Cybersecurity Manager, Poland; names the reasoning-visibility gap via a security-review lens. Skip call. Same Sage as RobertK leaders (66364).

Q1:

We are currently experimenting with AI-assisted coding and developer productivity tools, mainly around code generation, refactoring, documentation, and speeding up smaller implementation tasks. The most common gap we see is around visibility into the agent’s reasoning and decision process.

When reviewing AI-assisted PRs, reviewers usually see the final diff, but not always the full context of what the agent tried, rejected, or why it made certain trade-offs. That makes the review harder, especially when the change touches security-sensitive logic, infrastructure, authentication, permissions, or production workflows.

Q2:

Yes, this is a relevant challenge. When work-in-progress needs to be moved to another machine or handed over to another teammate, the context often has to be reconstructed manually from the code changes, PR comments, chat history, and local notes.

This is manageable for small tasks, but becomes inefficient when the agent has gone through multiple attempts, explored different approaches, or made assumptions that are not visible in the final diff. In those cases, the next person may need to re-discover the same context again.

We would be interested in understanding whether Pathbase can preserve session context, agent decisions, intermediate reasoning, rejected approaches, and make handover between developers more structured and auditable.

Q3:

A meaningful part of PR review comments are not only about what changed, but why something was done in a particular way. Typical questions are around design choices, edge cases, security implications, maintainability, hidden assumptions, and whether the generated code matches the original intent.

With AI-generated or AI-assisted code, this becomes even more important because the reviewer often cannot see the full reasoning path behind the change. This creates extra review effort and sometimes reduces trust in the output.

That is why we are interested in tools that can improve explainability, context sharing, and review confidence for AI-assisted development workflows. Pathbase sounds relevant from that angle, so a product pitch would be useful to better understand the practical use cases, integrations, and maturity of the platform.

JosephB — engineer RE-APPLICATION (meetingId 68380)

  • sage_id: 857 · connectionId: 65246 · dealId: 68320
  • Campaign: Engineers · Product Pitch · Stage Evaluating · 1250 credits · status PROPOSED
  • Assessment: 🟢 rekindle — passed in May on old product; re-applied to Pathbase focus, now comparing Claude Code vs Copilot. See 2026-07-01-josephb-reengagement. Same Sage as JosephB leaders (66451).

Q1:

Github Copilot + Databricks Assistant. Currently evaluating Claude Code as an additional / replacement to GHCP. Reviewers typically only see the final version, and review it with the developer who worked with the assistant. It is up to the developer to explain if/what options were suggested by the AI assistant (if at all…).

Q2:

I’m not a hands-on developer using it on a daily basis. But yes - this is situation that sometimes happens. There is no clear playbook on how to handle this situation. In many cases the developers must hand-off the context of what the AI context is (i.e. explain how they worked with the AI assistant). In some cases the target developer uses the AI assistant to analyze the previous session and resulting code. This is if they have direct access to that session, which is not always the case, since sessions sharing is quite limited (and doesn’t exist at all within Databricks Assistant).

Q3:

Honestly most are about the “what” and “how”, with emphasis on “how did you test it”. Why is mostly narrowed to reviewing the feature request and whatever is in it.

Initiative attached: AI Developer Enablement (started Dec 17, 2025; target Dec 2026).

CTOs campaign

Questions (all CTO applications answered these three):

  1. Roughly how many engineers at your company work with AI coding agents daily, and what happens to those sessions after the work ships? Are they retained anywhere today — vendor logs, internal storage, something you built yourselves — and if you ever needed to go back to one to understand why a change was made, could you?
  2. Imagine a complete, searchable record of every agent session behind your codebase — the intent, the alternatives considered, the dead ends — joined to your PRs, deploys, and incidents. What is the first question you would ask it? And who or what else at your company would use that record: engineers onboarding, reviewers, auditors, or your own agents and models?
  3. What would have to be true for agent session history to become a first-class system of record at your company? Specifically: where would the data need to live (your cloud, vendor-hosted, fully on-prem), what would need to be redacted or excluded before you’d allow capture by default, and is this something you would expect to build in-house or buy?

Link — cto (meetingId 67825)

Q1:

I would not claim one/a single exact number across 27 entities. The usage is growing, but our maturity is mixed and not always centrally visible. In many cases the session history stays in the tool or disappears from the engineering record. That is the gap: after code ships, we often have PRs, tickets, and commits, but not the full agent reasoning or decision trail.

Q2:

My first question would be: why was this change made, what alternatives were rejected, and did the agent touch sensitive logic or data paths? Security, engineering leads, reviewers, incident responders, auditors, and future agents could all use it. The value for us is faster review, better onboarding, stronger incident analysis, and more evidence when something breaks.

Q3:

For us it would need to sit in a controlled enterprise environment, ideally our cloud or a tenant we can govern. Capture by default would require clear controls for source code, secrets, PII, customer data, retention, access rights, and audit trail. I would expect a buy plus integration model, not a full in house build, unless the data risk was too high.

Leopold_R — cto (meetingId 67910)

Q1:

~3. There is nothing preventing deletion of work sessions, so there is not a written record to refer back to later.

Q2:

Interesting question - we would likely look for ways to improve the agents, so we’d start by examining the issues agents are encountering and identify themes so we can address them. The goal would be to make the agents more reliable, so they require less oversight. Probably all of the other roles you mentioned would use it although auditors may not use it at the moment. Moreso engineers and reviewers.

Q3:

I need to know what agent is, what tasks are assigned to each, what each agent has done and at what time and be able to tie that to its task(s). This would aid us in identifying what has gone wrong with an agent and why so the appropriate adjustments can be made. In terms of where that data can be hosted and whether we build/buy, we’re open.

DJC — cto (meetingId 68249)

  • sage_id: 11520 · connectionId: 65117 · dealId: 68189
  • Campaign: CTOs · Market Awareness · 1250 credits · status PROPOSED
  • Assessment: 🟢 — same strong handle as engineer-batch DJC. Excellent institutional-memory answer. Convert via the cheaper engineer app. Full eval: 2026-07-01-sagetap-djc-evaluation

Q1:

Our entire engineering organization relies heavily on AI coding agents every single day. Right now, the moment a PR is merged, the agent session and its reasoning essentially vanish. We might have fragmented traces left in temporary vendor logs or massive copy-pasted text blocks in Jira, but we have no structured retention whatsoever. If we had an incident today and needed to look back and understand exactly why an agent chose a specific implementation or discarded an alternative, we simply could not do it. That institutional memory is completely lost.

Q2:

During our next major incident or regression, the first question I would ask is: “What alternative approaches did the agent try and discard before settling on this specific code path?” Beyond immediate debugging, this record would fundamentally change how we do PR reviews by allowing reviewers to query the underlying intent without interrogating the human author. Longer-term, capturing this history is critical because we plan to use this exact system of record to train and fine-tune our own internal agents on our specific enterprise architecture and domain logic

Q3:

For agent session history to become a true system of record, the data must reside entirely within our own VPC. The continuous reasoning and intent behind our proprietary codebase is simply too sensitive to sit in a vendor-hosted environment. Before enabling capture by default, we would require strict redaction policies to guarantee that hardcoded secrets, PII, and secure configuration data are stripped from the logs. While we have considered building an internal logging solution, I strongly prefer to buy a purpose-built platform so my architecture teams can focus on our core infrastructure rather than maintaining a custom telemetry pipeline.

DannyG — cto (meetingId 68279)

  • sage_id: 11537 · connectionId: 65147 · dealId: 68219
  • Campaign: CTOs · Market Awareness · 1250 credits · status PROPOSED
  • Assessment: 🔴 call / 🟡 data — Principal Security Authority (secure-by-design gatekeeper), UK telecom. Skip call.

Q1:

Usage of AI coding assistants and agentic development tools is increasing across engineering teams, although retention of session history is generally fragmented and dependent on individual platforms. Today, much of the context behind AI-assisted development decisions is not systematically preserved, making it difficult to reconstruct the rationale behind changes, troubleshoot issues, or understand how a particular outcome was reached after deployment.

Q2:

One of the first questions we would ask is: “Why was this implementation approach selected over the alternatives considered?” A searchable record of agent interactions could provide valuable context for engineering teams, security reviews, onboarding, audits, and future AI systems. As agentic development becomes more prevalent, preserving decision-making context may become an important source of institutional knowledge and operational assurance.

Q3:

For agent session history to become a first-class system of record, we would need strong controls around data residency, access governance, retention, and redaction of sensitive information before capture. Given the sensitivity of engineering artifacts and potential inclusion of proprietary or regulated data, we would likely require deployment within our own cloud environment and integration with existing security, audit, and compliance controls. Whether we build or buy would depend on the platform’s ability to provide long-term governance and interoperability.

B. Profile (/sage-profiles/11537)

VP · Telecommunications · 10,000+ · United Kingdom · Activity 18 · Initiatives 4 · Job: Dec 2025–now

…Principal Security Authority, with a strong focus on AI security and security operations initiatives. My role centres on secure-by-design oversight, meaning any new application developed internally or major technology purchase must pass through my security architecture and risk review. I act as a key decision maker…

Pawel — cto RE-APPLICATION (meetingId 68908)

  • sage_id: 4532 · connectionId: 65760 · dealId: 68848
  • Campaign: CTOs · Market Awareness · 1500 credits · status PROPOSED
  • Assessment: 🔴 call / 🟡 data — third campaign application (engineer, now cto). Self-disqualifies as buyer + clean security-requirements list. Skip call; bank requirements.

Q1:

A good number of engineers work with Claude Code and Cursor daily. What happens to sessions after merge is a real gap, they’re not retained in any structured way today, so if a postmortem needed the reasoning behind a change, we likely couldn’t recover it.

Q2:

From my seat the first question would be why a change was made and what alternatives were rejected, for incident postmortems and audit. Engineers onboarding and reviewers would use it daily, our team would use it mainly after something’s already gone wron

Q3:

I’m not the architecture owner here, that’s our engineering and platform leadership. From security, the requirements would be clear: it lives in our VPC, PII and secrets are redacted before capture, and it maps to our data classification and audit standards. I’d want it built or bought under our governance, not the other way round.

CloudDB — cto (meetingId 68921)

  • sage_id: 8691 · connectionId: 65773 · dealId: 68861
  • Campaign: CTOs · Market Awareness · 1250 credits · status PROPOSED
  • Assessment: 🟢 — the CTO campaign’s “rare exceptional call.” Platform VP at UK finserv, ~5,000 engineers on agents daily, buy-open, AWS-hostable. 0 initiatives is the sole limiter.

Q1:

~5000 engineers using agents daily.

Session work, if stored by the harness, is local until deleted. Otherwise we typically lose this data.

Q2:

I think this is useful for a few use cases

Picking up code I wrote a while back New engineers onboarding to a codebase Incident / bug investigation MR review

(why does this line of code exist, what were the decisions, was a human involved)

Q3:

I think this is inevitable at some point. With regulation and provenance of AI driven decisions. We would likely run this data on the cloud in our AWS accounts

It depends where / how the data is stored as to what would need to be redacted. We store teams messages and emails today, this would fall into this category.

Open to a product in this space if it fits our needs.

B. Profile (/sage-profiles/8691)

VP · Financial Services · 10,000+ · United Kingdom · Job Jun 2024–now (~2 yrs) · Rating 5.0 (13 reviews) · Activity 11 · Initiatives 0 · single application (cto)

[org] A deeply technical senior engineering leader. Currently lead a team of ~400 cloud and software engineers to deliver enterprise ready core platforms as a product that are compliant, secure and provide a great internal developer experience. [tech adoption] Involved in the review and selection of new technologies around Cloud, Security, Platform Engineering, SRE, Developer Experience and AI. Cloud: AWS 32 / Azure 33 / GCP 24 / On-prem 11 · Tools: Wiz, CheckPoint CloudGuard, AWS, Azure, GitLab · Activity: passed Red Hat AI; interested Loophole Labs, RunWhen.

ggzuazo — cto (meetingId 68961)

  • sage_id: 1256 · connectionId: 65813 · dealId: 68901
  • Campaign: CTOs · Market Awareness · 900 credits · status PROPOSED
  • Assessment: 🟢 data / 🟡 call (geo) — most purchase-ready answer in the corpus; already stores sessions in Elastic for audit; final decision maker holding budget. Brazil (outside target geo).

Q1:

I have around 2500 engineers for now, but this is going to grow. Sessions are stored in Elastic for central storage, along with vendor logs like Copilot. For audit reasons I need to search into my elastic repo

Q2:

How easily can it be scaled, are there controls around it, and how much friction does it add? Users are multiples depending on the reason, if this is for explainability, for adding more context, auditors, compliance, engineers and reviewers primarily

Q3:

Audit data / Session Data must be stored in a repository that I can control, preferably hybrid, cloud, and on-prem; data must adhere to data classification and governance; sensitive data must be redacted for permanent storage. I would buy a solution like that. I have been using an elastic repository, but need something better.

B. Profile (/sage-profiles/1256)

Director (Sr. Director of IT Architecture) · Financial Services · 5,001-10,000 · Brazil · Rating 5.0 (158 reviews) — elite evaluator · Activity 126 · Initiatives 5 · Cloud: 50% on-prem · Tools: Datadog

[org] Experienced Enterprise Solutions Architect… manufacturing 15+ yrs, Financial 8+ yrs… [tech adoption] I’m the Enterprise Architect in charge of the evaluation and selection of many of the Technologies my company use. I’m the Final Decision Maker, holding the budget. Recent activity: interested in moonfort + ManticoreAI (Cloud Security & Compliance), Red Hat AI.

Brett_1949 — leaders (meetingId 66326) — NOT a campaign application

Brett reached out via a direct meeting request (message: “We help engineering leaders understand what their engineers are doing with agents. I’m new to Sagetap and it looks like you’ve had great experiences so far so reaching out!”) rather than answering campaign qualifying questions, so there are no qualifying answers to archive. Meeting completed 2026-05-18; identity revealed (Brett Dolecheck, Xylem). Call: 2026-05-18-brett-1949-sagetap-call.

See connections