Your AI Isn't the Advantage. Your Judgment Is - Sid Pednekar

An earnings call ends, the transcript comes in, and a copilot sends a summary to a research analyst. The analyst gets through the material sooner. But did the information that mattered reach the portfolio manager in time to act? Summarization introduces a tradeoff even when it works as intended. Condensing a transcript removes context, and the importance of a detail depends on the investment decision at hand.

Sid Pednekar, an AI, technology and data executive in asset management, uses two hypothetical firms to examine that distinction. Company B starts with a copilot and looks for a task it can speed up. Company A starts with a problem its analysts recognize: material signals reach them too late. That framing gives its engineers several possibilities to investigate. Analysts might lack the capacity to review the research, the underlying data might be poor, or the delay might occur when someone has to make a decision. Faster summaries address only some of those possibilities.

Pednekar cites survey findings that illustrate why the distinction matters. About 66% of respondents reported productivity gains, while roughly 40% reported cost reductions and 20% reported revenue growth. Those figures describe different outcomes. An engineering team can demonstrate that it saved analyst time and still have an open question about what the firm gained from it.

Company B can quickly assemble a portfolio of pilots. One bot summarizes documents, another retrieves data, and a copilot helps with the work in between. Experimentation has value, Pednekar acknowledges. The trouble comes when the number of pilots becomes the measure of progress. Each team can finish its assigned task while the delay that prompted the work persists across the research pipeline.

Company A concentrates engineering, analytics and AI capacity on that pipeline end to end. One possible design begins with the analyst stating an investment thesis. That gives the system a reason to pay attention to particular evidence, including evidence that could refute the thesis. Monitoring can run continuously, while the analyst investigates exceptions and chooses which developments warrant a closer look.

The analyst’s role changes in a consequential way. In the original sequence, the analyst reads a report, updates a financial model and sends a recommendation to a portfolio manager. Each handoff is a candidate for acceleration. In the redesigned workflow, the analyst also decides what proposition is worth monitoring in the first place. That is what Pednekar means by spending judgment. As reports and recommendations get cheaper to produce, deciding what merits investigation still consumes someone’s limited attention.

Choosing a research decision as the unit of work changes who needs to design the system. Pednekar imagines the familiar forward-deployed engineer working close to the business, but also the reverse arrangement, a portfolio manager working alongside the people building the tools. The portfolio manager can help decide what evidence matters. The engineer can see where the work crosses teams and which parts would otherwise be built several times.

For a data science team, Pednekar’s shared core includes the datasets, the semantic layer that gives the data meaning, and the accumulated experience of using both. Which questions has a dataset answered well? Where are its gaps? What tradeoffs did a predecessor encounter? A new data scientist who inherits only the data still has to repeat much of that investigation. Sharing the findings lets scientists pursue different questions while drawing on what colleagues have already established.

Much enterprise software assumes a person interacting with one application at a time. An agent may need context from one application to decide what action to take in another. Pednekar gives the example of a Slack bot that opens and closes tickets. The useful operation spans the conversation where work is discussed and the ticketing system where its state changes. Evaluating either application in isolation misses that dependency.

Pednekar distinguishes that workflow agent from an expert agent that makes subject knowledge accessible, or a chief-of-staff agent that tracks the state of work across an organization. The appropriate scope depends on how far the organization has progressed in making its knowledge reusable. Data quality and the ability to reuse data across applications are recurring obstacles. Naming the job an agent will do gives engineers a concrete way to identify which gaps in the underlying systems matter.

After deployment, an analyst may catch something the workflow missed. Fixing the immediate recommendation helps the person who receives it. For the correction to benefit the next analyst, something in the shared system has to change. Pednekar suggests that the lesson might become additional context or a new tool. He emphasizes preserving the evidence alongside it, so a colleague can see what prompted the correction and judge when it applies. A successful investigation deserves the same treatment.

The final accounting comes back to analyst time. If continuous monitoring frees capacity, where does that capacity go? In Company A’s proposed workflow, analysts can spend it investigating exceptions and weighing evidence that challenges a thesis. For a firm that began with late material signals, the most informative follow-up is whether those signals now reach the people making the decision sooner. The two companies are thought experiments. That outcome is what a team implementing the design would need to measure.