65 أسطر
3.0 KiB
Markdown
65 أسطر
3.0 KiB
Markdown
# Cumin Agent — Interview Questions
|
|
|
|
👉 **Before you start:** sign up and explore our Cumin agent at [os.solidpoint.ai](https://os.solidpoint.ai).
|
|
|
|
---
|
|
|
|
## Q1 — Design a Memory Module for the Cumin Agent
|
|
|
|
⏱ **Budget: ~15 minutes** · Weight: 30%
|
|
|
|
### Context
|
|
|
|
| Primitive | Purpose |
|
|
|---|---|
|
|
| **Containers** | Persistent Linux shells for private work (data processing, analysis, conversion). They stay alive for a conversation. |
|
|
| **Functions** | Serverless HTTP endpoints for public things (APIs, dashboards, websites). |
|
|
| **Workspace (object store)** | Flat file storage — every file Cumin produces lives here. |
|
|
| **Skills** | Markdown files Cumin reads to remember *how* to do tasks (its current, rudimentary long-term memory). |
|
|
| **Secrets** | Key/value pairs for credentials/tokens. |
|
|
|
|
**The gap:** Cumin has no real memory. Between turns it has to re-read its workspace files and skills from scratch. It forgets past conversations, past decisions, and past failures. There is no way to recall *"what did I learn last time I did this?"*
|
|
|
|
### Your task
|
|
|
|
Design a **memory module** for Cumin. Be concrete — we want to see storage choices, retrieval logic, and pseudocode, not hand-waving. Cover:
|
|
|
|
1. **Memory taxonomy** — define at least: *working* (short-term), *episodic* (past tasks/conversations), *semantic* (facts & patterns), and *procedural* (how-to, i.e. the evolution of "skills"). For each: what it stores, an example, expected size, and retention/TTL.
|
|
2. **Storage backends** — map each memory type to a concrete store. Where possible, map to **Ghaymah** products (vector store + embeddings, managed PostgreSQL, object storage).
|
|
3. **Write policy** — when does the agent write to memory, and what does it write?
|
|
4. **Read / retrieval policy** — how does the agent decide what to recall, and with what ranking (e.g. recency + semantic similarity + metadata filters)?
|
|
5. **Memory API** — pseudocode for `save`, `recall`, `search`, and (optionally) `summarize`/`forget`.
|
|
6. **Agent-loop integration** — pseudocode showing where memory is read/written during a normal turn.
|
|
7. **Failure modes & mitigations** — memory poisoning, staleness, context overflow, leakage between users, etc.
|
|
|
|
### Deliverable
|
|
|
|
Fill in the template below. Pseudocode blocks should be runnable-in-spirit (correct Python-ish, not perfect).
|
|
|
|
---
|
|
|
|
## ANSWER — Cumin Memory Module
|
|
|
|
|
|
|
|
---
|
|
|
|
## Q2 — General Product Feedback
|
|
|
|
⏱ **Budget: ~10 minutes** · Weight: 15%
|
|
|
|
Now that you've explored Cumin at [os.solidpoint.ai](https://os.solidpoint.ai), give us your honest, concrete feedback.
|
|
|
|
### Your task
|
|
|
|
1. **What works well** — what would make you keep using it?
|
|
2. **What's broken or confusing** — bugs, UX friction, missing features.
|
|
3. **What's missing** — the one capability that would most change how you use it.
|
|
4. **Positioning** — who is this *really* for, and how should we talk about it?
|
|
|
|
### Deliverable
|
|
|
|
Free-form, but be specific. Reference actual moments from using the product where possible.
|
|
|
|
> _Write your feedback here_
|