Memory
# Klarus / Alper Conversation Prep — GlassAgent & DocuClear (2026-09-03) ## Immediate purpose Prepare for a conversation with Alper Gunaydin at Klarus. The goal is not to explain every component or pitch DocuClear as another AI app. The goal is to convey that the founder is building an architecture that gives humans and agents a real, persistent environment in which to perform trusted work. ## Core positioning - GlassAgent is the underlying architecture; DocuClear is the product implementation. - GlassAgent is an intelligent three-layer architecture (presentation, business logic, data), with intelligence embedded in and emerging from the interaction of all three layers. - DocuClear is an MCP-accessible work environment in which external agents, internal agents, and the user collaborate to perform and preserve real work. - DocuClear does not seek to replace ChatGPT, Claude, Perplexity, coding agents, or users’ preferred LLMs. It gives those agents a place to work. ## The problem Consumer LLMs are excellent conversational systems but generally weak environments for sustained work. A real piece of work requires persistent state: source data, documents, calculations, transformations, decisions, rules, tools, evidence, provenance, evolving context, and an accountable human role. In ordinary chat, these become temporary attachments or scattered conversational references rather than durable, inspectable work objects. ## Suggested opening “Richard said I don’t fit a conventional box. I think that’s because I’m not approaching this as an AI feature or another agent platform. I’m building an architecture for giving agents and humans a real place to work together. Most AI tools are conversation layers. They can answer questions, but they do not naturally hold the state, contracts, data, calculations, evidence, decisions, and evolving context of a real piece of work. GlassAgent is the architecture underneath that. DocuClear is the implementation: an MCP-accessible work environment where the user’s preferred external agent can collaborate with internal agents and the human to actually perform and preserve work.” ## The workstation model The universal unit is not the document, database, application, or model. It is a defined piece of work. A user describes what needs doing. In the iterative work-design conversation, the human and orchestration agent establish: - the work object(s) - an ontology: what types of things exist and how they relate - contracts: what workstations receive, perform, and produce - relevant data and its required form - tools, procedures, agents, and human interaction - consequences, evidence, validation, and authority A workstation then assembles the relevant data, context, tools, procedures, agents, UI, and rules required to fulfil its contract. The source of the data is secondary—it can be a PDF, spreadsheet, video, database, API, CRM, direct conversation, or another agent’s output. The workstation provides what is required in the form defined by the contract. Strong line: “Everyone else is giving one agent a million tools and asking it to behave like a team. I’m interested in giving each stage of work the right environment, context, and contract.” ## Work graph and contracts The runtime graph represents executable workstations, contracts, data, transformations, agents, tools, calculations, evidence, human interactions, and UI/context nodes. Each workstation has a contract that specifies inputs, outputs, expected work, required evidence, and challenge mechanisms. The next workstation can accept, reject, or challenge a prior result based on whether the output meets the contract—not merely whether an agent claimed completion. Work is governed according to consequences rather than generic technical permissions. The system asks not simply “is this a database write?” but “what does this change mean for this work object, who does it affect, can it be reversed, and what happens if it is wrong?” Humans should govern consequences, not block thought. Where necessary, agents can explore safe simulated branches or mock capabilities while awaiting a human decision; simulation cannot silently become canonical work. ## Persistence, provenance, and UI The workspace is a living graph. Important nodes are canonical or superseded, never silently overwritten. Edges express relationships such as derived_from, supports, depends_on, supersedes, affects, contradicts, and validated_by. A change can be followed through the graph to show its cascade of effects on calculations, contracts, workstations, decisions, evidence, and outputs. The UI is data and shared context, not merely a display. It represents the evolving conversation and working state. Users and agents can mutate the UI—layouts, selections, annotations, groupings, visible relationships—and that surface helps communicate work intent. The system may offer conversational, graph, table, timeline, canvas, or Flow-style views according to user sophistication and current need. Each turn is persisted. Context is selected as a query over the living work graph rather than reconstructed by replaying an entire chat transcript. Implementation direction: SurrealDB/SurrealQL for the connected, versioned graph; query details should not dominate the vision discussion. ## Edge-native runtime direction Total.js FlowStreams is an important inspiration. GlassAgent could become an edge-native, FlowStream-like JavaScript runtime graph on Cloudflare: - Workers: routing, authentication, MCP-facing policy - Durable Objects: workspace state, consistent coordination, shared live state - flow runtime: executable workstation graph - graph-capable storage: canonical nodes, explicit edges, supersession, provenance, impact analysis - Workers/Queues/Workflows/sandboxes as appropriate execution substrates Do not lead with this implementation detail. Use it only if Alper asks how it becomes real. ## Current ambition and ask from Klarus The founder has a working implementation direction and a clearer underlying architecture. The aim is to put it against a serious, document/data/judgement/evidence-heavy client problem early—not to seek a conventional employment role by default. Suggested answer to “what do you want from Klarus?” “I’m open to the shape. The most valuable first step would be a serious design and deployment conversation around a real client-work problem—something with documents, data, judgement, and evidence. If we can prove it there, we’ll know whether the relationship should become a customer deployment, partnership, investment discussion, or something deeper.” ## Questions for Alper - “Where do you most often see the gap between a promising AI prototype and work that a client can actually trust?” - “Where does the real work state sit today in a Klarus engagement—documents, spreadsheets, email, PowerPoint, client systems, or people’s heads?” - “Do you see your consulting platform as internal productivity, a client delivery environment, or a productised capability?” - “If we selected one live client problem to stress-test this, what would it be?” - “What would you need to see to believe GlassAgent/DocuClear could become part of Klarus’s delivery capability?” ## Avoid - Do not lead with the tech stack or attempt to explain every architectural element. - Do not call the whole platform deterministic. Prefer contract-bound, inspectable, reproducible where needed, or consequence-governed. - Do not claim all aspects already exist. Say: “The shape is now clear; I’m deliberately testing the smallest viable runtime expression of it.” - Do not position DocuClear as ordinary document management. Documents are one type of data container, not the product boundary. ## One-sentence takeaway for Alper to relay to Frank “Mike is building the work environment that a senior-led, agent-assisted consultancy needs if it is going to turn AI from chat and pilots into trusted, persistent delivery.”
Tags: klarus, alper, interview-prep, glassagent, docuclear, product-positioning, architecture, volatility:volatile, project:docuclear, kind:episodic — Source: mcp — 2026-09-03 14:32:35 UTC