About Memory(One)
Our Mission
To leave the world in a better place than we found it by making it more efficient and functional. To ensure everyone has equal opportunities and that no one is left behind in the digitalisation and AI race.
Data foundation before agents. Business visibility before broad automation.
Memory(One) exists because many companies want AI, dashboards and automation before their systems and data can support them reliably.
The stronger starting point is the foundation underneath the tool: source systems, access, data movement, business definitions, dashboards, internal tools, monitoring, runbooks and operating ownership.
What Memory(One) builds
Memory(One) builds AI-ready data and automation infrastructure. It connects systems, builds data flows, organises operational data into queryable views, creates dashboards and internal tools, then adds controlled automations and AI-enabled workflows where the foundation can support them.
Founder
Alexander Watts is a software engineer and computer scientist, an avid optimiser and a work-smarter kind of person.
Who Memory(One) works best with
Memory(One) works best with organisations that have several systems, recurring reporting pain, operational complexity and a real need for better data, dashboards, workflows or AI-enabled capability.
Managed Automation is a separate route for an organisation with one bounded repetitive workflow, a clear process owner, manageable exceptions and a need for Memory(One) to operate the automation. Broader data foundations, several connected workflows or custom operating surfaces belong on the Assessment, Foundation or Operations route.
How Memory(One) works
- Start with the business question or operating problem.
- Map systems, data, ownership, access and risk.
- Choose the smallest credible route.
- Build in an approved environment with testable acceptance criteria.
- Add monitoring, runbooks and a clear operating owner.
- Improve through an agreed project or support model.
Delivery, accountability and access
Each written scope defines the work, client responsibilities, named operating roles, acceptance evidence, access method, monitoring or support boundary, handoff and escalation path for that engagement. This page does not promise direct access to a particular person or imply that a named individual personally performs every delivery or support activity.
What keeps the work usable after handoff?
The written scope defines acceptance, deployment, repository and documentation delivery, runbooks, credential handling, named operating owners, fallback and any post-launch support. A client-owned project is handed over to the agreed client owner and support route; a managed service continues only within its active Care or Managed Support arrangement. These are scoped continuity controls, not a promise of founder access, direct delivery or unlimited support.
Who owns the data, code, platform and outputs?
For Foundation, Operations and Custom Build projects, engagement-specific ownership and deployment are defined in the written agreement and generally use client-owned or client-approved environments.
Managed Automation is different. The customer owns its data, documents, process knowledge and outputs. Memory(One) retains its managed platform, shared connectors, reusable templates and managed configuration model, and hosted operation depends on the active care subscription.
Location and direct contact
Memory(One) is located in Copenhagen, Denmark.
- Email: [email protected]
- Telephone: +45 93 95 14 96