What is CORE?

CORE is building what it describes as a Personal AI OS — an AI system designed to remember context, connect to the tools a person already uses, and take actions on their behalf.

What makes CORE interesting to me is its evolution.

The project started around a problem that is becoming increasingly important in AI: context fragmentation. People use ChatGPT, Claude, Cursor, email, Slack, GitHub and other tools, but the context created in one place often does not naturally follow them into another.

CORE's current product goes beyond memory. Its public repository describes persistent memory, tasks, coding agents, browser capabilities, messaging, voice and integrations with more than 50 applications.

That changes the product question.

The interesting challenge is no longer simply:

"Can an AI remember?"

It becomes:

"Can all this context and capability feel like one coherent system that actually helps the user get things done?"

The problem CORE is attacking

Modern AI tools are powerful, but they often operate inside separate contexts.

A developer may have:

• Code and issues in GitHub

• Planning in Linear

• Conversations in Slack

• Email in Gmail

• Meetings in a calendar

• Documents in Notion

• AI conversations in several different assistants

The information exists, but the relationships between that information are difficult for a user to maintain manually.

CORE's approach is to create a persistent context layer that can connect information across these systems.

Its public architecture describes a temporal knowledge graph, meaning information can be connected not only by what it is, but also by how it changes over time.

That is an interesting foundation for an AI assistant that is expected to understand an ongoing relationship with its user.

CORE's product evolution

The evolution of CORE is particularly interesting.

The initial problem was AI memory and context portability.

The product then expanded toward persistent context.

From there, CORE added tasks, agents, tools and actions.

Today, the public product positioning is much broader: a Personal AI OS.

This creates a large opportunity, but it also creates a product challenge.

The more capabilities an AI system has, the more important the experience connecting those capabilities becomes.

A user should not have to understand the underlying architecture to get value from it.

They should simply be able to express an outcome and have the system understand what context and tools are required.

What I find technically interesting

There are several parts of CORE's public architecture that stand out.

1. Persistent memory

CORE describes memory that can index information from services such as email, meetings, GitHub, Linear, Slack and assistant conversations.

This moves the assistant away from a single conversation and toward a longer-term relationship with the user.

2. Temporal context

A traditional database can tell you what information exists.

A temporal knowledge graph can potentially help answer another question:

"What was true, when was it true, and how did it change?"

For a personal AI system, this distinction can become important.

Projects change.

Decisions change.

People change roles.

Plans change.

The assistant needs to understand those changes rather than simply accumulating facts forever.

3. Agents and actions

CORE's public repository describes coding sessions, browser actions, terminal access, messaging and task execution.

This moves the product from:

"Tell me something"

toward:

"Do something for me."

That transition is strategically important because the value of an assistant can increasingly be measured by completed outcomes rather than generated responses.

The product opportunity I would investigate first

My first investigation would not be another feature.

I would investigate the path from:

First login → first connected source → first useful task → first successful outcome.

For a product this broad, the first successful outcome could be more important than the number of features a new user sees.

For example:

A developer connects GitHub.

They ask CORE:

"Which issues should I work on first?"

CORE gathers relevant context, understands the project and produces a useful answer.

If that experience works reliably, the user immediately understands the value of persistent context.

This is the kind of experience I would want to measure.

Hypothesis: the first-win problem

This is a hypothesis, not a claim about CORE's current metrics.

As the product surface expands, a new user may have many possible things they can do.

That creates an opportunity to investigate whether the product should guide users toward one meaningful outcome rather than asking them to discover the system themselves.

I would measure:

• Signup to first integration

• First integration to first task

• First task to successful outcome

• Time to first useful result

• Percentage of users who return after the first successful outcome

The goal would be to understand where users experience the product's first moment of real value.

Hypothesis: integration discovery

CORE has a large integration surface.

That is valuable because more connected context can make the assistant more useful.

But there is an important product question:

Should users choose integrations first, or should CORE recommend integrations based on the outcome they want?

I would test two onboarding approaches.

Approach A — Apps first

"Connect GitHub, Slack, Gmail, Linear, Notion..."

Approach B — Outcome first

"What do you want CORE to help you accomplish?"

For example:

"I want CORE to help manage my engineering work."

The system could then recommend the minimum integrations required for that workflow.

This could reduce unnecessary setup while still allowing advanced users to connect additional systems later.

Again, this is an experiment I would validate with product data rather than assuming the current onboarding has a problem.

Hypothesis: make memory visible

Persistent memory is powerful, but users may eventually want to understand what the system remembers.

I would investigate a simple memory interface showing:

Fact → Source → History → Current state → Actions influenced

For example:

"Project X uses PostgreSQL"

Source: GitHub repository

Last confirmed: September 2026

Related decision: Architecture discussion

This could make the memory system more understandable and easier to correct.

The key question would be:

Can a user easily answer: "What does CORE currently know about me?"

Autonomy creates a second product challenge

As AI systems gain the ability to act, another problem becomes increasingly important:

How much autonomy should the user give the system?

An assistant that can read information is one thing.

An assistant that can send messages, modify code, open pull requests, browse websites or execute tasks is different.

The product therefore needs a clear relationship between:

Capability → Permission → Action → Result

Users should be able to understand what the assistant can do, what it is allowed to do and what it actually did.

I would investigate whether every consequential action can be explained in a simple way.

For example:

"CORE accessed GitHub because you asked it to analyse your open issues."

"CORE created this task because you enabled autonomous task execution."

"CORE opened this pull request after completing the coding session."

Trust becomes part of the product

For an AI OS, trust is not only a security feature.

It is part of the user experience.

The more systems CORE connects to, the more important it becomes for users to understand:

• What information is available to CORE?

• Where is that information stored?

• What can CORE access?

• What can CORE change?

• Which actions require approval?

• Which actions can happen automatically?

• Why did CORE take a particular action?

CORE publicly emphasizes self-hosting, security and user control.

The product opportunity I would investigate is how clearly those technical properties are communicated during everyday use.

A technically strong security architecture is valuable.

A security model that users can easily understand is even more useful from a product perspective.

Developer ecosystem

CORE is also interesting from an ecosystem perspective.

The project is open source and publicly developed on GitHub.

Its repository currently describes integrations, coding agents, browser capabilities, messaging and self-hosting.

That creates the possibility of an ecosystem where developers can extend the assistant rather than relying only on functionality shipped directly by the core team.

The challenge becomes maintaining a consistent experience while the number of tools and capabilities grows.

That makes architecture and product design increasingly connected.

Benchmark claims

CORE's public repository reports an average accuracy of 88.24% on the LoCoMo benchmark.

I would treat this as a company/project-reported benchmark claim rather than independently verified evidence of overall product quality.

A benchmark can tell us something useful about a specific capability.

It cannot by itself tell us whether users consistently get value from the entire product.

For the product, I would therefore look alongside benchmarks at behavioural metrics such as successful task completion, retention, correction rates and user outcomes.

What I would test

If I were working with the CORE team, I would start with five experiments.

Experiment 1 — First successful outcome

Measure the complete journey from signup to first successful task.

Experiment 2 — Goal-first onboarding

Compare outcome-based onboarding with integration-first onboarding.

Experiment 3 — Memory transparency

Give users a clear timeline showing what CORE remembers, where it came from and when it changed.

Experiment 4 — Autonomy controls

Test whether users understand and feel comfortable with different levels of autonomous action.

Experiment 5 — Outcome-based product navigation

Instead of presenting capabilities as separate features, organize important workflows around outcomes.

For example:

"Manage my engineering work"

"Prepare for my meetings"

"Keep my projects organized"

"Handle repetitive tasks"

The underlying tools can remain complex.

The user experience does not need to be.

Questions I would ask the founders

If I were speaking with the CORE team, these are some of the questions I would want to understand:

1. What percentage of new users complete their first successful task?

2. What is the most common first task?

3. Which integration has the strongest relationship with activation?

4. How many integrations does a typical active user connect?

5. Where do users most frequently stop during onboarding?

6. Which capability has the strongest relationship with long-term retention?

7. How frequently do users inspect or correct their stored memory?

8. How often do users enable autonomous actions?

9. Which autonomous actions most frequently require user confirmation?

10. What percentage of generated plans eventually become completed actions?

These answers would help distinguish where the largest product opportunity actually exists.

My current thesis

CORE's evolution is interesting because it is moving from an AI memory problem toward a broader Personal AI OS.

The opportunity is not simply to add more capabilities.

The harder product challenge is making all those capabilities feel like one coherent system to the user.

The strongest version of this product would make complexity disappear behind outcomes.

The user should not need to think:

"I need memory + GitHub + Slack + browser + coding agent."

They should be able to think:

"I need this problem solved."

CORE's architecture can potentially make that interaction possible.

The next question is how effectively the product turns that technical capability into a simple, trusted and repeatable user experience.

Research note

This analysis is based on publicly available information about CORE and its public developer ecosystem.

The observations and experiments above are not claims about CORE's internal metrics, user behaviour or business performance.

Where I identify potential problems or opportunities, they should be treated as hypotheses to validate with the company's own data and user research.