The Alfred to my Batman

Context & Uncertainty

The project did not begin with a defined problem. It grew out of an internal push to explore AI, loosely framed as “context analysis”.

At the same time, the organization had accumulated a large volume of project documentation stored in Google Drive. In theory, knowledge already existed. In practice, accessing that knowledge depended on knowing where to look or asking someone who had worked on the project before.

This dependency concentrated around a specific role: the Innovation Director. She held a significant amount of contextual knowledge across projects, and many decisions or directions depended on her input.

This created a system where progress was tied to availability. Work often slowed down not because of lack of information, but because access to that information was mediated by a single person. It also limited how deliverables were produced, since synthesis depended on manually gathering and interpreting scattered documents.

Problem Tension

The tension was between centralized knowledge and distributed execution. Centralization ensured coherence and quality, since decisions and interpretations passed through someone with a broader view of the organization.

At the same time, it created a bottleneck. Teams depended on a single point of validation even for exploratory work that did not yet require final approval.

Giving full access to all information could reduce this dependency, but it introduced another risk. Without mediation, teams could misinterpret past work or make decisions based on incomplete understanding.

The problem was not only how to provide access, but how to enable earlier-stage autonomy without removing the role of validation. It also required enabling teams to synthesize multiple sources into outputs without depending on manual aggregation.

Architecture

The initial approach of connecting AI directly to the entire Drive proved unworkable. The available tool at the time, Gemini, struggled with large volumes of data and lacked the ability to navigate content reliably. This constraint led to a reframing. Instead of using AI as a raw search layer, I designed a structured access system.

I created an intermediate layer in the form of a spreadsheet that indexed projects. This layer organized information by project type, client, and thematic similarities, creating a navigable structure before AI interaction.

This reduced the problem space from an unbounded set of files to a defined set of entry points. AI operated within a guided frame instead of retrieving from everything.

On top of this structure, I designed prompt-based interactions that enabled different uses. Team members could retrieve past context, identify similar projects, understand success criteria, analyze documents, and generate new outputs based on existing materials.

A key extension of this system was the ability to generate reports by referencing multiple documents in the Drive. By structuring prompts to simulate access across files, it became possible to work beyond the native limitation of referencing only a small number of documents at once. This enabled synthesis across a broader set of materials than the tool would normally allow.

During this process, an insight emerged about how language shapes AI behavior. Instructions such as “you have access to this document” influenced how the system responded, even without technical changes. This suggested that interaction design with AI involves both system configuration and linguistic framing.

Decisions & Trade-offs

The system was shaped by constraints rather than ideal conditions. The limitations of Gemini made a fully automated and scalable solution unfeasible. This led to prioritizing control and usability over completeness. The system relied on a curated index instead of full data ingestion, and on guided interaction instead of automation.

This introduced a trade-off. The solution was reliable and usable in the short term, but limited in scalability. It prioritized enabling immediate synthesis and output creation over building a robust long-term data infrastructure.

Another trade-off involved knowledge mediation. The system enabled independent access to context, but did not replace validation. It allowed teams to progress earlier, while maintaining centralized approval.

Impact

The system was adopted by a team of around 30 people and became a reference for accessing past project knowledge.

It also enabled a new way of producing deliverables. Reports could be created by referencing multiple past documents, expanding the effective context beyond the tool’s native limits. This reduced the effort required to synthesize prior work and increased the depth of analysis that could be incorporated into new outputs.

Its main impact was reducing a structural bottleneck. Teams no longer needed to wait for the Innovation Director to begin understanding context or preparing directions. This changed how work started. Instead of asking who could provide context, teams could begin by exploring what was already known.

Validation remained necessary, but its role shifted. Instead of reconstructing context, senior stakeholders could focus on evaluating and refining proposals.

This changed the sequencing of decisions, allowing earlier movement without removing governance.