PaulShin

I believe that all light and darkness coexist.

Wow,, your comment really resonated with me. There’s a lot of insight in how you framed it.

I’ve actually been thinking about this as primarily a technology problem and, somewhat embarrassingly, I’m building something to try to address it.

When teams talk constantly across chat, calls, and meetings, a lot of the real work gets buried in the noise. Decisions are made. Tasks are implied. Commitments are spoken out loud and then they dissipate.

What we’re building is a system that extracts only the actionable parts from those conversations, turns them into tickets, assigns them automatically, and in some cases even lets AI execute the task directly. Humans do what only humans should do. AI handles what can be automated.

Recording conversations is important but motion is what creates value. If nothing moves, nothing compounds.

I don’t think adding another storage location solves the problem. Understanding relationships and triggering execution might.

Would genuinely love your thoughts on whether that’s directionally correct or if I’m still treating a wetware problem as software.

I got this

LoL

Seen from that perspective, it makes sense to shift toward a more modern, familiar look

Yes, I agree

Exactly. they're not visiting the site for an artistic experience. Thank you for the clarification.

You're right. Rather than trying to stand out in a unique way, it's better to look like something already trusted and established. Thanks for the insight!

True, but what if the pen wrote everything for you and even turned your notes into tasks that got done automatically?

Good job bro

Thank you, this is incredibly valuable feedback. You've hit on a critical point about trust and privacy, and I want to be very clear that we agree with you completely.

If my description made it sound like a "Big Brother" tool that monitors conversations, that's a total failure of my explanation, and I'd like to clarify.

The "automatic extraction" is not a secret surveillance process. The AI assistant is designed to act like a helpful teammate, not a spy. It operates openly in-channel and essentially asks, "Hey, that sounds like a to-do item. Should I create a ticket for you?"

The key is that

the user is always in control. Nothing gets turned into a formal to-do item without a user's explicit confirmation or manual click.

So the goal isn't to monitor the "real" chats, but to help the team capture the action items they've already publicly agreed to, acting more like a personal assistant for the team members themselves, not for management.

You are absolutely right about the human nature to CYA in team environments, and our design philosophy must respect that.

This feedback is a gift because it shows our messaging is causing the exact wrong impression. Thank you again. With this clarification, does the concept feel less like surveillance and more like a potentially useful tool?

Hi HN,

We're building a simple app that lets you automatically extract and manage to-do tickets right from your team's conversations.

I'm building this because my team and I constantly face a problem: actionable items get lost in the stream of our chat app (Slack, Teams, etc.), or we waste time manually moving them to a separate task manager like Jira or Notion. This manual copy-pasting is our biggest friction. When you move a task, you lose the original context of

why that task was created in the first place. This context-switching kills our productivity.

Our solution makes this process seamless. Here’s how it works:

You chat with your team, yourself, or an integrated AI assistant.

The AI understands the dialogue (e.g., "Could you fix the deployment bug by Friday?") and automatically suggests creating a to-do ticket from that message.

Of course, you can also manually turn any message into a ticket with a single click.

Each ticket is intrinsically linked to the conversation thread, so the full context is always preserved. These tickets can then be managed on a Kanban board or a calendar without ever leaving the app.

Essentially, our goal is to eliminate the 'collaboration tax' by merging the place of discussion with the place of action.

My questions for HN are:

Would you or your team use a tool like this?

What are your biggest frustrations with your current chat + task management workflow?

Does the "automatic task extraction" sound genuinely useful, or does it feel like a gimmick that might get annoying?

For this to be a "must-have" product for you, what feature would it absolutely need to get right?

Thanks for your feedback!

I'm DongYoon, founder of Markhub (https://markhub.ink).

We're building a chat app that automatically creates and manages your to-do list right from your conversations.

I started this for a simple reason: I was tired of the soul-crushing 'copy-paste' work of moving decisions from Slack over to Notion or Jira. So much context gets lost in that process, and it just creates more "work about work."

Our core idea is simple: a chat message and a to-do item shouldn't be two separate things you have to keep in sync. In Markhub, the conversation is the task. It's not a copy; the conversation itself becomes the to-do, and all the context is automatically preserved.

Our bigger vision is to do for collaboration what GitHub did for Git. We’re not reinventing chat or kanban boards; we’re building the seamless 'workflow layer' on top that finally makes them work together.

We're currently in a private beta and would love to hear from HN users who feel this same pain. We’ve been fortunate to get early traction with large enterprise clients (including a ~$200k on-premise deal), but now we're looking for feedback from smaller, agile teams.

Any and all feedback is a gift. Thanks!

That's an even more precise and insightful framing. You're absolutely right—the catalyst was licensing, and the technical problem of SCM was, in a sense, already "solved." Thank you for sharpening the point further.

You've actually given me the perfect "Part 2" of the analogy "the relationship between Git and GitHub."

Yeah, Git is the powerful, low-level engine. Technically brilliant, but with a notoriously steep learning curve. The real explosion in adoption came when GitHub wrapped it in a user-friendly product with a clear workflow (pull requests, issues, etc.). GitHub didn't reinvent SCM; it reinvented the collaboration workflow on top of it.

That's exactly how we see the problem we're tackling. The "protocols" of modern work already exist: real time chat, task lists, documents. But they exist as separate, low-level primitives, like Git commands. The "collaboration tax" comes from users having to manually act as the interface between them.

Our goal is to be the "GitHub for general collaboration." To take those existing primitives and build a seamless, opinionated workflow on top where the connections are automated. The user shouldn't have to think about the "protocol"; they should just be able to work.

So, your point is well taken and helps clarify our position. We're not trying to build the "Git" (the core primitive). We're trying to build the "GitHub" (the intuitive workflow layer that makes the primitives powerful for everyone).

And that philosophy is baked right into our name. The reason we're called Markhub is because we're building a central "Hub" where every "Mark" a team makes a message, a decision, a task, a document can live together in a single, seamless flow.

Haha, touché. You're sharp.

But they left some of the palantíri behind for the new age to communicate. We're just trying to build a less treacherous version.

Haha, wise words indeed. We’re definitely aiming to be the Council of Elrond, not Sauron. The goal is alignment, not domination.

You've absolutely nailed the history and ethos of Git, and it's a crucial distinction. Thank you for the clarification. You're right, it wasn't a "product" in the modern sense.

My analogy wasn't intended to be about the UI or its 'one thing well' philosophy, but about the category of friction it eliminated.

Before Git, the coordination overhead for code was immense think manual patches and diffs. Git didn't write the code for anyone, but it automated away that specific, painful "collaboration tax," freeing developers to focus on the actual programming.

I see a parallel today, but the "collaboration tax" has moved. It's now the manual, repetitive work of translating team conversations into structured tasks. We believe that specific friction can also be automated away, freeing teams to focus on the actual execution.

So, you've helped me refine the analogy: It's not about building a product like Git, but about tackling a problem in the same way Git did by automating a specific, painful type of coordination overhead.

Multiple monitors definitely make window switching easier—totally agree. The snag we keep hitting isn’t the physical hop, but the cognitive hop:

- A decision lives in Slack, - its rationale hides in Notion, - the actual task ends up in Jira.

Even with three screens, someone still has to copy-paste and re-explain. That’s the part we’re trying to erase: let a Slack message turn itself into a task/doc record without leaving the thread.

If that hand-off were automatic, would you still feel the need for so much screen real-estate, or is multi-monitor workflow a must for you regardless?

Side note We’re prototyping this idea right now. If you’re curious and willing to give feedback, drop me a note at (admin@markhub.ink) and I’ll send over a private link.

Appreciate your take!

Fair point no tool can manufacture intrinsic motivation. At the same time, even highly motivated people hit friction: digging through chat history, duplicating context, or chasing down “who owns this.”

The goal of what we’re building isn’t to make someone work; it’s to strip away the overhead that slows down people who already want to.

Think of it like version control: Git doesn’t write code for you, but it removes enough coordination pain that good engineers ship more often. We’re aiming for the same effect between conversation and execution—same motivation, less drag.

From our side, the north-star is a radically simple answer: let a single chat thread end all that visible complexity. One place, one flow, nothing to copy or sync. That’s the product we’re building toward.

Curious have you seen lightweight workflows that actually cut this friction without adding new layers?

Thanks for the links—Brooks and Zawinski are exactly the guard-rails we keep taped to the monitor.

No Silver Bullet: We’re not chasing a “one tool to rule them all.” The essential complexity—humans aligning on what to do can’t be deleted; we’re only trying to strip away the accidental part (manual copy-pasting).

Zawinski’s Law: Instead of cramming every feature into one bloated app, we’re limiting scope to a single object model:

A message, a task, and a doc are the same object, just rendered in different views.

Chat ≠ Task Manager ≠ Wiki, but they sit on the same data layer, so hand-offs happen automatically rather than by re-typing.

Anything beyond that (CRM, billing, email) stays as integrations no temptation to rebuild an Outlook clone.

So the direction is “context cohesion without feature creep.” If we can kill the copy-paste tax and still keep each tool honest to its purpose, we think that’s the sweet spot.

Curious where you’ve seen this approach succeed or crash and burn in real teams.

Great point context switching hurts more than app switching when the tools don’t enforce a single source of truth.

Role clarity: Slack = capture, Notion = synthesize, Jira = track.

Reality: Decisions still leak out of channels, tasks lose owners, docs go stale.

Unifying everything in one mega-app can create new clutter, unless the app itself preserves context automatically. That’s the angle we’re exploring: keep roles clear, but let the hand-off happen inside the flow so people don’t have to think about it.

Curious how does your team make sure a Slack decision doesn’t die before it reaches Jira? Any workflow tricks that actually stick?

P.S. We’re prototyping a tool that tries this “context-in one flow” idea (still private beta). If anyone’s curious—or has horror stories about chat→task hand-offs—happy to swap notes. DM or reply here.

This is a fascinating model, thanks for sharing. The classic "engineering as the bottleneck" problem is something every product engineer feels, so I deeply appreciate the desire to solve it.

I'm intrigued by this API-first approach, and it's left me with a few questions from my perspective as an engineer who builds product features:

How do you handle features with complex UI/UX? While a push notification is a perfect fit, how would a non-eng person build, say, a new analytics dashboard with interactive charts or a multi-step modal view? Is there a clear line where a feature's complexity means it has to go back to the engineering team?

Who owns the holistic user experience? With different people building features decentrally, how do you ensure the product feels cohesive and not just a collection of disconnected Zapier flows? I imagine maintaining a consistent design system and user journey could be a challenge.

You mentioned the "duct-tape logic" problem. This is the part that resonates—and worries—me most. Do you have a formal process for refactoring or "graduating" a successful duct-tape solution into a core, robust, engineer-built API? How do you manage that accumulating technical debt?

As an engineer, the idea of focusing solely on clean, scalable APIs is incredibly appealing. At the same time, there's a certain joy in crafting and shipping a polished feature directly to users. It's a really interesting trade-off you've presented.

Thanks again for the thought-provoking post.

Great question. As a founder also working on my next project, the fear of "solving fake problems" is something I think about every day. Thanks for asking it.

For me, the single most frustrating part of any data-related task isn't the data itself. It's the "work about the work" – the soul-crushing feeling that I'm doing the same thing two or three times in different windows.

The biggest irony is that this is often caused by the very "smart work" tools that are supposed to make us more productive.

My typical workflow looks like this:

A request for data comes in on Slack. I pull the data, analyze it, and share a conclusion in the Slack thread. Then, I have to go to Jira to create a ticket that summarizes what I just said on Slack. Finally, I have to open Notion to write a brief document explaining the findings for the record. The context is constantly being copied, pasted, and fragmented. It's exhausting and feels like a waste of human potential.

This isn't a pitch, but this exact frustration is the only thing I'm focused on solving right now. My entire thesis is that the endless context switching between our communication layer (chat) and our execution layer (tasks, docs) is the biggest source of "fake work" in modern companies.

I'm building a tool where that entire "copy/paste the context" cycle is eliminated. A place where the conversation is the task, is the doc, is the context—all in one single flow.

I'm just a founder who is sincerely obsessed with this problem, and it's validating to see I'm not the one who feels this pain.

This is a deeply frustrating and energy-draining situation. Thank you for sharing it so candidly. The fact that your motivation has taken a hit is a completely natural and valid response to poor leadership. You are not the problem here.

I'm a founder based in Seoul, so I can't comment on the specifics of US corporate culture or the internal politics at your company. However, I believe the framework for making a decision in such a situation is universal. When I or my team members have faced difficult career choices, I've found it helpful to analyze it through three lenses:

1. The Learning Lens: Are you still growing? Despite your manager, are you still acquiring valuable skills and experiences that you couldn't easily get elsewhere? Is the work itself still challenging you in a positive way?

2. The Mission Lens: Do you still believe? You said you still care about the mission. The question is, how much? Is your belief in the mission and the product strong enough to endure this manager for another 6, 12, or 18 months? Can you still find a way to contribute effectively to that mission?

3. The Life Lens: What is the daily cost? This is the most important question. What is the daily tax this situation is imposing on your mental and emotional health? Is this cost sustainable over time? Is the person you are becoming in this environment—perhaps more cynical or stressed—someone you respect?

No one on the internet can answer these questions for you. My only advice is this: take an hour, write down your honest answers to these three questions. Don't decide today. Put the paper away, and read your own words again in a week.

Often, seeing your own thoughts written down, separate from the daily frustration, makes the path forward surprisingly clear.

Ultimately, your career is long, but your life is happening now. Your well-being is the most important asset you have. Making a conscious choice for yourself, whatever that may be, is a victory in itself. Wishing you clarity.

You got me. I guess that's my own practical example of the 'human > AI > human' collaboration you described.

Jokes aside, this is a fantastic, insightful reply. Thank you. You've given a name to the pain: 'task-set inertia' and the cost of the 'stealth meeting.' Painfully accurate.

The advice here is gold, especially treating the AI like a 'junior dev' on a 30-min ticket vs. a 'rubber duck' you ping every two lines. That really crystallizes the right mental model.

Very cool that you're tackling this head-on with Recontexter. Solving the 're-hydrating context' problem is such a critical challenge. I'll be following your work.

Great question, and very timely. We've been tackling this exact problem at my startup, Markhub. The cost of hot storage for observability data, especially logs, can quickly become a significant line item.

We adopted a tiered approach that's working well for us so far:

1. Hot Tier (Last 7 Days): Elasticsearch. For our real-time debugging and immediate operational needs, nothing beats the query speed of Elasticsearch. We keep a rolling 7-day window of all logs here. It's expensive, but essential.

2. Warm Tier (7-90 Days): AWS S3 Standard. After 7 days, our log shipper (Fluentd) automatically archives the logs to S3. If we need to investigate an older issue, we can still query these logs directly using AWS Athena. It's much slower than Elasticsearch, but for occasional, deep-dive investigations, the cost savings are massive.

3. Cold Tier (After 90 Days): S3 Glacier Deep Archive. After 90 days, the logs are transitioned to Glacier Deep Archive via S3's lifecycle policies. This is purely for long-term compliance and "break glass in case of emergency" scenarios. It's incredibly cheap to store, but we know that retrieving it would be a slow and deliberate process.

The key lesson for us was to be realistic about our actual query patterns. We found that over 95% of our queries were for logs less than 3 days old. This data-driven approach allowed us to be aggressive with our tiering strategy without sacrificing critical visibility.

Great topic. We've moved past simple automation and into the era of orchestration, as you said.

But I believe there's another layer to this shift: the move from Horizontal AI Agents to Vertical AI Agents.

Horizontal agents (like general-purpose chatbots or assistants) are powerful, but they lack deep, contextual understanding of a specific team's unique workflow. They can answer general questions, but they can't manage a complex design review process from end to end.

At my company, Markhub, we're betting on the power of Vertical AI. We're building an AI teammate, MAKi, that is not a generalist. It is an expert in one thing: the chaotic workflow of turning scattered team conversations into structured, actionable work.

It's designed to understand the specific context of a project—the feedback on a PDF, the follow-up questions in a chat, and the resulting tasks on a Kanban board. It doesn't just automate tasks; it orchestrates the entire feedback and execution lifecycle.

My belief is that the most successful enterprise AI won't be a single, all knowing agent. It will be a network of specialized, vertical agents like ours, each mastering a specific, high-value business process.

As a founder who also acts as the head of product for our B2B SaaS, Markhub, this is a topic I'm passionate about. Your use cases especially using an LLM to understand an undocumented codebase are very familiar.

My biggest pain point wasn't just executing individual tasks with an LLM, but the "context loss" that happens between those tasks. The summary from my research, the user feedback from a Slack thread, and the technical spec for the feature all lived in separate places.

So, we took a different approach. We built our own AI teammate, MAKi, directly into our collaboration platform. We don't just "use" an LLM; we've made it the central OS for our entire product development cycle.

Here's our day-to-day workflow:

1. User Feedback Synthesis: Instead of manually reading user interviews or community posts, I ask MAKi: "Summarize all feedback from the last 7 days related to our mobile app, and categorize them into 'Bugs' and 'Feature Requests'." MAKi reads all the scattered conversations and generates a structured report.

2. From Feedback to Spec: We then discuss that report in a chat thread. Once we decide on a feature, I ask MAKi: "Take this conversation and our decision, and write a technical spec document for the dev team, including the user problem, proposed solution, and key action items."

3. Living Documentation: This is the most powerful part. As developers work on the feature, their discussions and code commits (via integration) are all linked to that initial conversation. Later, anyone can ask MAKi: "What was the original reason we built the PWA notification feature?" and it will instantly pull up the entire history from the first user feedback to the final decision document.

We've found that the true power of LLMs isn't just in answering questions, but in creating a persistent, searchable, and intelligent memory for the entire team.

This is a fantastic question that gets to the heart of a huge pain point in applied AI. You're not missing something obvious; you've just discovered a gap in the market that we're obsessed with solving at my startup, Markhub.

Your problem of cleaning a dataset ("remove all records without foul language") is functionally identical to the problem our users face every day: cleaning up messy team conversations ("turn this chaotic chat into a clear list of tasks").

Our approach has been to build an AI agent, MAKi, that acts as an interface layer on top of unstructured data. Instead of writing complex scripts, our users simply talk to MAKi.

For example, they can highlight a long conversation and give it a prompt like, "Extract all action items from this, assign them to the relevant person, and set due dates for next Friday."

MAKi parses the request, understands the context, and generates structured To-Do items, effectively "cleaning" the conversational data into an actionable format. We call this a "Conversation-Driven Workflow."

While our use case is collaboration, the underlying technology to "interact with a dataset via prompts" is exactly what you're looking for. It seems like the next wave of AI tools won't just be models, but intuitive interfaces for manipulating data with natural language.

Interesting thread. We're building Markhub, a B2B collaboration SaaS, and we have a pragmatic, hybrid approach to our observability stack. Our philosophy is: use open source where it gives us control and flexibility, and use managed SaaS where it saves us time and engineering overhead.

Here's our stack:

Logs: We self-host a simple stack using Fluentd to collect logs, which are then shipped to Elasticsearch for storage and analysis. It's powerful, gives us full control over our data, and is more cost-effective at our scale than a managed logging service.

Metrics & Monitoring: For this, we decided not to reinvent the wheel. We use Datadog. The out-of-the-box dashboards, alerting, and deep integration with our cloud provider (AWS/GCP) save our small team hundreds of hours. The cost is justified by the engineering time we save.

Traces: We're currently using Datadog's APM for tracing as well, as it's tightly integrated. However, we're actively exploring moving to OpenTelemetry for more vendor neutrality in the future.

It's working out well. The key has been to be honest about our most valuable resource: engineering time. We self-host where we have a clear need for control (logs), and we pay for a service where the platform provides undeniable value and speed (metrics/monitoring).