Inspiration
Every organization has a memory.
It is distributed across Slack conversations, Jira tickets, Google Drive documents, meeting discussions, incident reports, data catalogs, code repositories, post-mortems, architecture decisions, and — most importantly — the people who were there when important decisions were made.
But organizations rarely have a reliable way to remember what they already learned.
A team may spend weeks investigating a technical problem only to discover that another team solved — or failed to solve — the same problem two years earlier. An engineer may start a database migration without knowing that a similar migration previously caused a production incident. A new employee may ask questions that were already answered hundreds of times in old conversations. And when an experienced engineer leaves the organization, much of the context behind their decisions leaves with them.
This is what we call institutional amnesia.
The problem is not that enterprises lack data.
The problem is that they lack context at the moment of decision.
That observation inspired ContextBridge — Institutional Memory AI Agent.
The original vision of ContextBridge was to create an AI-powered institutional memory layer capable of connecting enterprise communication and knowledge sources and turning fragmented organizational history into useful, searchable context.
For the DataHub hackathon, we evolved that idea further.
Instead of building another application that simply stores or retrieves organizational knowledge, we wanted ContextBridge to become an agent that does real work.
The key question became:
What if an AI agent could understand what an organization is doing right now, remember what happened in the past, connect the two, and intervene before the organization repeats an old mistake?
That led us to DataHub.
DataHub provides a structured understanding of the organization's current data environment — datasets, schemas, ownership, lineage, dependencies, metadata, and relationships between data assets.
ContextBridge provides the missing historical dimension:
- What decisions were made?
- What failed?
- Why did it fail?
- What lessons were learned?
- Who was involved?
- What should we do differently this time?
This creates the foundation for our central idea:
DataHub knows what's connected.
ContextBridge knows what happened.
Together, they protect what happens next.
What It Does
ContextBridge is an autonomous institutional memory and decision-intelligence agent.
It is designed to operate as an intelligence layer above the tools an organization already uses, rather than forcing employees to constantly switch to another chatbot.
The system combines two kinds of context.
1. Current-State Context
Provided through DataHub:
- datasets
- schemas
- metadata
- ownership
- lineage
- downstream dependencies
- relationships between data assets
2. Historical Organizational Context
Provided through ContextBridge's institutional memory:
- decisions
- failures
- incidents
- lessons learned
- projects
- people
- technical discussions
- documents
- historical outcomes
The agent then connects these two dimensions.
Instead of answering only:
"What is this dataset?"
ContextBridge can work toward questions such as:
"Has this dataset or a related system been changed before?"
"What happened the last time we attempted something similar?"
"What dependencies could be affected?"
"Who has actually worked on this before?"
"Are there historical failures that should influence the current decision?"
"What should the engineer check before proceeding?"
The Agentic Decision Loop
The core of ContextBridge is an agent loop:
OBSERVE → PLAN → INVESTIGATE → FUSE CONTEXT → REASON → ACT → REMEMBER
Observe
The agent detects a relevant task, event, request, or change.
For example:
Migrate
customer_ordersto PostgreSQL 16.
Plan
Instead of immediately producing an answer, the agent determines what information is required to understand the task.
Investigate
The agent can use DataHub's agent-accessible context to investigate the current data environment.
It can retrieve information such as:
- dataset metadata
- schema
- ownership
- lineage
- dependencies
- related assets
At the same time, ContextBridge searches its institutional memory for historical context.
Fuse Context
The agent combines:
Current DataHub Context + Historical Institutional Memory
This is where ContextBridge becomes substantially more useful than a simple semantic search system.
Reason
The agent evaluates the relationship between the current task and historical events.
It considers evidence such as:
- similarity between current and previous work
- affected assets
- historical outcomes
- known failure causes
- people involved
- related decisions
- available documentation
Act
Depending on the confidence and risk level, the agent can:
- provide contextual information
- warn the user
- recommend actions
- identify relevant experts
- prepare an action
- request human approval
- write useful knowledge back into the organization's memory
Remember
The final step is critical.
The outcome of today's work should become useful context for tomorrow.
This creates a continuous organizational learning loop:
$$ \text{Current Work} \rightarrow \text{Investigation} \rightarrow \text{Decision} \rightarrow \text{Outcome} \rightarrow \text{Lesson} \rightarrow \text{Institutional Memory} \rightarrow \text{Future Work} $$
The organization does not simply solve problems.
It learns from solving them.
The Flagship Scenario
To demonstrate the concept, we designed a representative scenario around a database migration.
An engineer creates a task:
Migrate
customer_ordersto PostgreSQL 16.
Normally, this looks like a standard engineering task.
But ContextBridge detects the activity and begins investigating.
First, it uses DataHub to understand the current environment.
The agent discovers information such as:
- the
customer_ordersdataset - its schema
- its owner
- its lineage
- four downstream assets
- related dependencies
The agent then asks a second question:
Has something similar happened before?
ContextBridge searches institutional memory.
It discovers that a similar PostgreSQL migration was attempted in Q3 2023.
The previous migration failed.
The historical root cause was:
Connection-pooling misconfiguration
ContextBridge then connects the historical event with the current DataHub context.
The result is an intervention such as:
⚠️ HIGH-RISK HISTORICAL MATCH
The agent can then recommend:
- reviewing the previous post-mortem
- validating connection-pooling configuration
- inspecting downstream dependencies
- checking the previous rollback strategy
- consulting engineers who worked on the previous migration
The important part is not the warning itself.
The important part is how the warning was produced.
The agent did not simply retrieve a random document containing the words "PostgreSQL migration."
It combined:
current data context + lineage + historical memory + relationships + evidence
to produce a decision-relevant intervention.
The principle is simple:
Instead of discovering the failure again, the organization remembers it before repeating it.
Institutional Memory
ContextBridge treats organizational knowledge as a living network rather than a collection of isolated documents.
Its memory can contain relationships between:
- people
- datasets
- projects
- decisions
- failures
- incidents
- lessons
- documents
- technical systems
For example:
Engineer
↓
worked on
↓
PostgreSQL Migration
↓
affected
↓
customer_orders
↓
caused
↓
Production Incident
↓
root cause
↓
Connection Pooling
↓
documented in
↓
Post-mortem
This relationship-oriented model allows the agent to ask much more meaningful questions than simple keyword search.
It can move from:
"Find documents about PostgreSQL."
toward:
"Find people, assets, decisions and historical failures connected to this PostgreSQL migration."
Expertise Discovery
Another important capability is discovering:
"Who actually knows this?"
Traditional enterprise search often relies on job titles or directory information.
ContextBridge aims to identify expertise through demonstrated historical involvement.
For example, if an engineer previously:
participated in the PostgreSQL migration
investigated the connection-pooling issue
contributed to the post-mortem
helped design the rollback strategy
then that person becomes highly relevant when another similar migration begins.
The agent can therefore help route a problem to the people who have actual experience, rather than simply the people whose job title appears relevant.
This transforms institutional memory into an organizational expertise network.
Knowledge Graph
ContextBridge represents relationships between organizational entities through a knowledge graph.
The graph can connect:
People
↕
Projects
↕
Datasets
↕
Decisions
↕
Incidents
↕
Failures
↕
Lessons
↕
Documents
NetworkX can support relationship modeling and graph analysis, while D3.js can provide an interactive visualization layer.
ChromaDB can provide semantic retrieval across stored organizational knowledge.
Together, these components allow ContextBridge to combine:
graph relationships + semantic similarity + DataHub metadata + LLM reasoning.
How We Built It
ContextBridge is designed as a modular architecture.
At the center is the ContextBridge Agent.
Around it are several layers.
DataHub Context Layer
DataHub provides the agent with structured knowledge about the current data environment.
The hackathon-oriented architecture uses DataHub's MCP Server / Agent Context capabilities as the bridge through which the agent can access relevant DataHub context.
This makes DataHub part of the agent's actual reasoning workflow.
Institutional Memory Layer
Enterprise knowledge from sources such as:
Slack
Jira
Google Drive
Gmail
meeting transcripts
can be transformed into structured institutional knowledge.
Relationship Layer
NetworkX represents relationships between people, systems, datasets, decisions, incidents and lessons.
Semantic Memory Layer
ChromaDB provides vector-based semantic retrieval so that the agent can find conceptually related historical knowledge even when the wording is different.
Reasoning Layer
Google Gemini provides language understanding, contextual synthesis, similarity interpretation and recommendation generation.
Application Layer
The user-facing system is designed around a React + TypeScript interface with views for:
Command Center
Agent Activity
DataHub Context
Institutional Memory
Investigation Results
Interventions
Expert Finder
Knowledge Graph
Analytics
Administration
API Layer
A REST API connects the frontend, agent services, memory services and integrations.
Deployment Layer
Docker provides a reproducible deployment model so that the system can be run as a complete stack.
ContextBridge as an Intelligence Layer
One of our most important design decisions was not to make ContextBridge another application employees must constantly visit.
Employees already work inside tools such as Jira and Slack.
Therefore, the ideal experience is:
ContextBridge is invisible when unnecessary, visible when useful, and strongly visible when risky.
For a normal task with no meaningful historical connection:
No interruption.
For a potentially useful historical connection:
💡 Related institutional context found.
For a high-risk historical match:
⚠️ Similar previous failure detected.
This makes the agent proactive without becoming disruptive.
The ContextBridge User Experience
The platform has three major interaction modes.
1. Embedded Intelligence
ContextBridge can surface relevant intelligence inside existing workflows such as Jira or Slack.
The user continues working normally.
2. ContextBridge Command Center
The central application provides a deeper environment for:
agent monitoring
institutional memory
interventions
investigations
expertise discovery
analytics
3. DataHub Context
The user can inspect:
datasets
schemas
lineage
owners
dependencies
connected historical memory
This creates a unified view of:
What is this data?
and:
What happened around this data before?
Challenges We Ran Into
One of the biggest challenges was changing our thinking from "AI that answers questions" to "AI that performs useful work."
A traditional chatbot can wait for a user to ask:
"What happened during the last PostgreSQL migration?"
But an agent needs to recognize that a current task is related to a historical event without requiring the user to know that the event exists.
That changes the architecture significantly.
The agent must determine:
What is happening now?
What context does it need?
Which tools should it use?
Which DataHub entities are relevant?
Which historical memories are relevant?
What relationships connect them?
How strong is the evidence?
Should the user be interrupted?
What action should be recommended?
What knowledge should be preserved afterward?
Another challenge was ensuring that DataHub is genuinely central to the hackathon implementation.
We did not want to simply mention DataHub in the project description.
The agent needs to actually use DataHub context to understand the current state of the data environment before making its recommendations.
A third challenge was balancing autonomy with trust.
An enterprise agent cannot simply perform every action it wants.
A recommendation such as:
"Review this historical post-mortem."
can be automated safely.
A potentially high-impact production change should involve human approval.
Therefore, ContextBridge uses a risk-aware human-in-the-loop model.
Accomplishments That We're Proud Of
The biggest accomplishment is the conceptual transformation of institutional memory from a passive repository into an active intelligence system.
We are particularly proud of five aspects.
1. Turning Memory Into Action
The system is designed not merely to store historical knowledge but to surface it when current work makes that knowledge relevant.
2. Making DataHub Part of Agent Reasoning
DataHub becomes the agent's understanding of the current data environment.
The agent can reason using:
schema + lineage + ownership + dependencies + historical context
3. Creating a Proactive Agent
ContextBridge does not depend entirely on users knowing what to ask.
The agent can identify potential relationships between current work and historical events.
4. Connecting Organizational Expertise
The Expert Finder concept allows the agent to identify people based on previous involvement with similar problems.
5. Building a Continuous Learning Loop
The ultimate vision is:
Work → Decision → Outcome → Lesson → Memory → Better Future Decision
This means every completed task has the potential to improve the organization's future decision-making.
What We Learned
The project taught us that building an enterprise AI agent is fundamentally different from building a conversational AI interface.
A chatbot focuses on:
Question → Answer
An agent focuses on:
Goal → Context → Tools → Investigation → Decision → Action → Memory
That difference influenced almost every part of our architecture.
We also learned that context quality is as important as model quality.
A powerful LLM without accurate organizational context can still produce a generic answer.
But when the model is given:
current DataHub lineage
real ownership
actual dependencies
historical failures
previous decisions
relevant experts
supporting evidence
the AI can produce much more useful decision support.
Another important lesson was that organizational memory should not be treated as a static database.
Knowledge changes.
People change.
Systems change.
Decisions become obsolete.
New incidents create new lessons.
Therefore, institutional memory needs to behave more like a living knowledge graph than a document archive.
Finally, we learned that trust is essential.
An enterprise agent should not simply say:
"I think this is risky."
It should be able to show:
Why am I saying this?
Which DataHub assets are involved?
Which historical event is relevant?
What evidence supports the connection?
How confident is the assessment?
What action do I recommend?
This evidence-first approach is central to ContextBridge.
What's Next for ContextBridge - Institutional Memory AI Agent
The hackathon version is the beginning of a much larger vision.
1. Deeper DataHub Integration
We want to expand the agent's use of DataHub so that it can understand increasingly complex data environments and use lineage and metadata as first-class reasoning context.
The long-term goal is for DataHub to become one of the primary sources of truth that the agent consults before making data-related decisions.
2. More Enterprise Agents
ContextBridge could evolve from one general institutional-memory agent into a team of specialized agents.
For example:
Data Quality Agent
Detects historical data-quality failures and investigates current anomalies.
Pipeline Agent
Understands pipeline dependencies and previous incidents before suggesting changes.
Migration Agent
Analyzes historical migrations before new migrations begin.
Governance Agent
Uses organizational knowledge and DataHub metadata to identify governance risks.
ML Reliability Agent
Connects training datasets, features, models and deployment history to identify potential ML risks.
These agents could share the same institutional memory.
3. Autonomous Data Engineering
A future version could move beyond recommending actions and begin producing useful artifacts.
For example:
DataHub Context→Agent Investigation→Generate Pipeline Configuration→Validate Lineage→Create Git Branch→Open Pull Request→Human Approval
This would move ContextBridge even further into the Agents That Do Real Work category.
4. Institutional Memory for AI Agents
The next major evolution is not only helping humans remember.
It is helping other AI agents remember.
Imagine an organization where multiple agents are working simultaneously.
One agent discovers a failure.
ContextBridge records the lesson.
Months later, another agent begins a similar task.
Instead of repeating the same investigation, the new agent can query institutional memory and inherit the previous lesson.
This creates a shared organizational memory for both:
humans + AI agents
5. Enterprise Memory Flywheel
Our long-term vision is a continuous organizational learning system:
Observe→Investigate→Decide→Act→Measure→Learn→Remember→Improve
Every decision becomes potential future context.
Every failure becomes a warning.
Every successful solution becomes reusable knowledge.
Every expert becomes part of an organizational expertise network.
And every new AI agent inherits the lessons of the agents and people that came before it.
The Bigger Vision
We believe the future of enterprise AI should not be another collection of isolated assistants.
Organizations will increasingly have AI agents operating across:
data
engineering
finance
operations
governance
security
customer systems
But autonomous agents need something humans have always relied on:
memory.
Without memory, an agent can repeatedly make the same mistakes.
Without context, an agent can make technically plausible but operationally inappropriate decisions.
Without relationships, an agent cannot understand who owns a system, what depends on it, who has worked on it, or what happened before.
ContextBridge is designed to become that missing layer.
A shared institutional memory and decision-intelligence layer for humans and AI agents.
The ultimate vision is an organization where knowledge does not disappear when people leave, where failures become reusable lessons, where expertise can be discovered instead of rediscovered, and where AI agents can understand not only what the organization is doing now, but also what the organization has already learned.
Final Vision
ContextBridge is built around a simple belief:
Your enterprise should not have to learn the same lesson twice.
DataHub provides the structured understanding of the present.
ContextBridge provides the memory of the past.
The AI agent connects them to influence the future.
DataHub knows what's connected.
ContextBridge knows what happened.
Together, they protect what happens next.
### One important point
This version uses exactly the Markdown structure you asked for:
- `## Inspiration`
- `## What It Does`
- `## How We Built It`
- `## Challenges We Ran Into`
- `## Accomplishments That We're Proud Of`
- `## What We Learned`
- `## What's Next for ContextBridge - Institutional Memory AI Agent`
So when you paste it into **Devpost**, those `##` headings will render as proper section headings, and the `**bold**` sections will render as bold.
I also kept the **complete detailed model** rather than turning it into a short Devpost description. The content follows the version you uploaded, including the flagship PostgreSQL scenario, agent loop, DataHub role, institutional memory, expertise discovery, architecture, UX, challenges, accomplishments, lessons, and future roadmap. :contentReference[oaicite:1]{index=1} :contentReference[oaicite:2]{index=2} :contentReference[oaicite:3]{index=3}
Built With
- ai-agents
- datahub
- enterprise-ai
Log in or sign up for Devpost to join the conversation.