Most AI applications I see today have the same weakness: they forget everything. You ask a question, get an answer, and the context effectively disappears. That's fine for simple interactions. It's a terrible model for organizations that make hundreds of decisions, run dozens of projects, and accumulate years of lessons that rarely survive employee turnover.
I built FoundryAI to explore a different approach. Instead of treating AI as a stateless assistant, I wanted to treat organizational knowledge as a first-class system component. The result is a platform that stores decisions, lessons, policies, and project outcomes, then uses them as context for future reasoning.
The interesting part wasn't generating text. The interesting part was making historical knowledge actually usable.
What the System Does
At a high level, the system combines four layers:
- Persistent storage for organizational data.
- Memory retrieval and search.
- AI reasoning over retrieved context.
- Interfaces for exploring historical decisions and generating new project plans.
The core idea is simple.
Every organization produces knowledge:
- Why a migration happened.
- Why a vendor was selected.
- What failed during a project.
- What policies were introduced.
- What lessons were learned afterward.
Most of this knowledge ends up scattered across documents, meetings, chat messages, and employee memory.
FoundryAI attempts to centralize that information into a searchable memory system.
Instead of asking:
"What does the model know?"
the system asks:
"What does the organization already know?"
That distinction drives almost every design decision in the project.
The Architecture
The architecture is intentionally straightforward.
User
↓
Frontend Application
↓
Memory Retrieval Layer
↓
Persistent Storage
↓
AI Reasoning Engine
↓
Structured Response
The frontend provides several major capabilities:
- Dashboard
- Memory Vault
- Organizational Genome
- Time Machine
- Decision Graph
- Project Generator
The backend stores structured organizational records and retrieves them when needed.
The AI layer is responsible for analysis, summarization, recommendation generation, and project planning.
The retrieval layer is the most important part because it determines what information the model actually sees.
Without retrieval, the model has no organizational memory.
The Real Problem Was Context
The first implementation made a mistake that seems obvious in hindsight.
I tried passing too much information into the model.
The logic looked roughly like this:
const memories = await getAllMemories();
const prompt = `
Question:
${userQuestion}
Organizational Memory:
${JSON.stringify(memories)}
`;
This worked when the database contained a handful of records.
It failed immediately once memory volume increased.
The model was receiving huge prompt payloads containing every memory entry regardless of relevance.
The result was:
- Slow responses
- High token consumption
- Context limit failures
- Worse reasoning quality
The model wasn't becoming smarter. It was drowning in information.
That forced a redesign.
Retrieval Beats Bigger Prompts
The second version adopted a retrieval-first approach.
Instead of sending the entire memory vault, the system retrieves only the most relevant records.
The workflow became:
User Question
↓
Memory Search
↓
Top Relevant Records
↓
AI Analysis
↓
Response
The implementation looks more like:
const relevantMemories =
await searchMemories(userQuestion);
const prompt = `
Question:
${userQuestion}
Relevant Context:
${relevantMemories}
`;
This change reduced prompt size dramatically while improving answer quality.
The AI now reasons over focused evidence rather than an indiscriminate database dump.
The lesson is simple:
Context quality matters more than context quantity.
The Corporate Time Machine
The feature I find most interesting is the Time Machine.
Organizations often remember what happened but forget why it happened.
The Time Machine attempts to reconstruct decision context.
A user can ask:
- Why did we adopt a particular framework?
- Why was a migration approved?
- What lessons came from a failed rollout?
- What influenced a policy change?
The system retrieves historical records and generates a narrative explanation.
Instead of returning isolated documents, it tries to connect:
- Decisions
- Outcomes
- Lessons
- Policies
into a coherent timeline.
That turns historical data into something closer to institutional memory.
Modeling Knowledge as Connected Objects
Another design choice was storing knowledge in structured categories rather than a generic notes database.
A memory record might be:
{
"type": "decision",
"title": "Cloud Migration",
"content": "Selected AWS due to...",
"visibility": "private"
}
Another might be:
{
"type": "lesson",
"title": "Deployment Failure",
"content": "Rollback automation was missing..."
}
This structure enables richer relationships between records.
The Decision Graph visualizes those relationships.
A decision can lead to:
- Outcomes
- Lessons
- Policies
which themselves become searchable context later.
This creates a growing knowledge network instead of a collection of isolated documents.
Generating Projects From Organizational Knowledge
The Project Generator started as a simple idea generator.
It evolved into something more useful.
Instead of producing generic plans, the generator creates structured outputs:
- Vision
- Requirements
- Architecture
- Roadmap
- SWOT Analysis
- Risks
- Success Metrics
The workflow is:
Project Idea
↓
Historical Context
↓
AI Reasoning
↓
Structured Blueprint
The important detail is that generated projects can incorporate organizational history.
A company that repeatedly encounters certain operational problems should not receive the same recommendations as one that doesn't.
That historical grounding is where organizational memory becomes valuable.
Building the Dashboard Was Easier Than Building the Data Model
Most people notice dashboards first.
The dashboard wasn't the difficult part.
Modern frontend tooling makes charts, cards, filters, and visualizations relatively straightforward.
The harder challenge was deciding what organizational knowledge actually looks like when represented as data.
Questions included:
- What qualifies as a memory?
- What qualifies as a lesson?
- How should visibility work?
- How should relationships be stored?
- How should retrieval rank relevance?
Those decisions had more impact on the final system than any UI choice.
The user interface simply exposes the underlying model.
If the model is poor, no amount of visual polish can compensate.
What I Learned
Three lessons stand out.
1. AI Is Not Memory
This seems obvious, but many systems blur the distinction.
Language models generate responses.
Memory systems preserve knowledge.
Treating them as separate concerns produces better architecture.
2. Retrieval Matters More Than Prompt Engineering
The quality of retrieved context often influences outputs more than elaborate prompting strategies.
A good model with bad context performs poorly.
A good model with focused context performs surprisingly well.
3. Historical Context Is Undervalued
Organizations spend enormous effort generating knowledge and surprisingly little effort preserving it.
Most decisions become disconnected from their rationale within months.
Capturing the reasoning behind decisions may be more valuable than capturing the decisions themselves.
Where This Could Go
The current implementation focuses on organizational memory and decision intelligence.
The next logical step would be deeper knowledge graph capabilities:
- Causal relationship mapping
- Automated lesson extraction
- Decision impact forecasting
- Organizational pattern detection
The long-term goal isn't to build another chatbot.
It's to build a system that remembers enough about an organization to provide historically informed reasoning rather than isolated answers.
Most AI systems start every conversation from zero.
Organizations don't.
That's the gap I wanted to explore.
Top comments (0)