A Portfolio for the Systems Around AI Agents

The builder need: make connected work legible

AI engineering work often arrives as a scattered collection of repositories, experiments, deployed tools, research notes, and client-facing services. A memory system may inform an agent project. A data-extraction pipeline may become the foundation for retrieval-augmented generation, or RAG, which gives a model relevant outside context before it answers. Without a map, it is difficult for a collaborator, hiring team, or prospective user to understand how those pieces relate.

MuLIAICHI/MuLIAICHI addresses that presentation problem as a profile repository. Rather than shipping one library or application, it presents Mustapha Liaichi’s stated focus areas and routes readers toward selected work. The repository is tagged portfolio and ui, which fits its role as a navigational front door.

That distinction matters. This is not a project to install, run, or evaluate through a package manifest. It is a concise technical portfolio for a builder who describes himself as an AI engineer and product builder based in Morocco.

A map of four related concerns

The README groups the work around autonomous agents, memory, retrieval, and production data infrastructure. Those categories create a useful framing for the linked projects.

First is agent memory. The repository describes this as episodic, semantic, and procedural memory. In plain terms, episodic memory concerns past events or interactions; semantic memory concerns facts and concepts; procedural memory concerns reusable ways of doing work. The stated goal is to give agents useful context without wasting tokens, the units of text models process.

Second is retrieval. The README emphasizes finding conceptual gaps and measuring whether retrieved context covers a question. That is a more specific concern than simply returning search results. It asks whether the material supplied to a model is sufficient for the task at hand.

Third is AI-ready data. Here the stated need is dependable extraction pipelines for RAG, model training, research, and market intelligence. Finally, the profile points to agent tooling: Model Context Protocol, or MCP, integrations and automation systems that connect models to business tools.

Taken together, these sections describe a practical chain: acquire dependable data, retrieve relevant context, manage what an agent retains, and connect the agent to operational systems. The README does not document a single integrated architecture spanning these areas, so that chain should be read as an editorial organization of the portfolio rather than as a claim that every linked project is one system.

Selected projects make the scope concrete

The portfolio’s strongest move is to pair each broad theme with named work.

CogDB is described as a unified memory database for AI agents. Its stated interface combines vector search, temporal knowledge, and reusable procedures. Vector search generally finds material by semantic similarity rather than exact keyword matches. Temporal knowledge adds a time dimension to stored information, while reusable procedures point toward retaining operational know-how alongside facts and documents.

TopoRAG is presented as an application of topological data analysis to detect conceptual gaps and blind spots in retrieved context. The profile does not explain the implementation, evaluation method, or results, so the useful takeaway here is the problem it foregrounds: a retrieval pipeline needs a way to identify what it may be missing, not only what it has found.

The profile also links an n8n Marketplace Research project, described as turning more than 6,000 public workflows into market analysis, a machine-learning dataset, and a fine-tuned Llama workflow generator. It links a Jira MCP Server for letting AI assistants manage Jira issues, sprints, and projects through MCP. These examples connect data work and agent tooling to recognizable operational tasks.

Other selected work broadens the portfolio further. The README points to Apify Actors, described as more than 20 production data products, and to Sentinel, characterized as an open negative-result study of a pump.fun trading strategy using paper trading and on-chain evidence. Including a negative-result study is notable as a portfolio choice because it makes room for documented limits, not only successful outcomes.

The workflow is discovery, not installation

For a visitor, the documented workflow is straightforward. Start with the focus areas to identify the relevant problem category. Then follow the selected project link that corresponds to that category. Readers who want longer-form context can use the linked Research Notes, The Scraping Report, and Medium writing referenced in the README.

This organization is useful for people evaluating adjacent capabilities rather than looking for a single dependency. Someone exploring agent memory can begin with CogDB. Someone concerned with retrieval quality can begin with TopoRAG. Someone building model-to-tool integrations can inspect the Jira MCP Server. The profile does not provide setup instructions, APIs, benchmarks, or dependency information for these linked projects, so those questions belong in their individual repositories.

Be precise about the technical evidence

The repository metadata lists its language as Unknown, and no package, Python, Rust, or Go manifest is supplied. As a result, this profile repository does not verify a runnable project stack or dependencies of its own.

The README names tools that the author says he reaches for, including Python, TypeScript, PyTorch, FastAPI, Next.js, PostgreSQL, Docker, Apify, Crawlee, Playwright, n8n, MCP, and Linux. That is useful context about stated working preferences, but it should not be mistaken for a dependency list for this repository. There is no manifest here to establish versions, packages, or the technology choices of any particular linked project.

That boundary is a practical lesson for technical portfolios: keep navigation clear, but keep technical claims scoped. A profile README can establish the problems a builder works on and make the next repository easy to find. It cannot substitute for project-level documentation when readers need reproducible setup, architecture details, or evidence of behavior.

For a focused view of this portfolio and its links to the underlying work, inspect MuLIAICHI/MuLIAICHI.