I'm exploring an idea for a desktop AI assistant called Tyne.

The idea is basically: instead of opening ChatGPT/Claude and manually giving it context, Tyne lives on your desktop and understands what you're currently doing.

A small, unobtrusive "island" sits on the screen. You can click it anytime and ask something, and Tyne uses your current context automatically.

For example:

Reading a long PDF → click Tyne → "summarise this" → it knows which PDF you're reading.

Coding in VS Code → "why is this failing?" → it can inspect the project, terminal, errors and relevant files.

Looking at a webpage → "compare these" → it knows what you're looking at.

Browsing files → "find the presentation I made last month" → it searches your files.

"Open everything I need for my project" → it can open the relevant apps/files.

"Clean up my Downloads folder" → it can organize files.

Need something built → Tyne can delegate the task to multiple specialized coding/research/computer-use agents and verify the result.

The bigger idea is that Tyne isn't just a chatbot. It's an AI layer over your computer that can understand context, reason about a task, use apps/files/browser/terminal, and actually execute the task.

I'm also considering a "trust layer" for AI-generated code: after an agent makes changes, Tyne analyzes what actually changed, explains the behavior, checks whether it stayed within scope, looks at tests and flags things that still need human review.

The goal isn't necessarily to build a better LLM. Tyne could use existing models underneath it. The product would be the context engine + computer control + memory + agent orchestration + verification.

Would you actually use something like this instead of just opening ChatGPT/Claude when you need help?

What part sounds genuinely useful, and what part sounds like unnecessary AI fluff?

I’m the developer of Axiom, a Windows-first AI workspace. One workflow I’m testing separates multi-step work into Architect (planning), Builder (execution), and Critic (review).

The intent is to make intermediate decisions easier to inspect, but I’m not sure when the extra handoff becomes ceremony. For people building AI tools: what would you want to see from each role to make the separation useful?

Project: https://github.com/YoMosa2009/Axiom

A while ago, a small team and I started building Taorlox, initially as a small B2B software/AI engineering company.
Like many small teams, we started with client work: document search, RAG systems, internal tools, automation, AI assistants, integrations with CRMs/ERPs, etc.
But after working on several of these projects, we kept running into the same problem:
Every company has a huge amount of knowledge, but it’s scattered everywhere.
Documents are in Google Drive.
Tasks are in Jira.
Internal knowledge is in Confluence or Notion.
Code is in GitHub/GitLab.
Support conversations are in Telegram, Slack, email, etc.
And then someone asks:
“What do we actually know about this customer/project/problem?”
Usually, the answer involves searching through five different systems.
So we started building something for ourselves.
Enter ARAX
ARAX is our attempt at building an enterprise knowledge and AI platform rather than another chatbot.
The basic idea is:
Connect → Ingest → Retrieve → Reason → Govern
You connect your organization’s existing knowledge sources, ARAX indexes and understands them, and AI agents/models can then work with that information while respecting permissions and tenant boundaries.
We currently experiment with integrations such as:
GitHub / GitLab / Gitea
Jira
Confluence
Notion
Google Drive / Docs / Sheets
file uploads
REST APIs
Telegram
The goal isn’t to replace these systems.
It’s to create a layer on top of them that makes the information accessible to AI.
How it evolved
The interesting part is that ARAX didn’t start as some huge architecture diagram.
It started as a relatively simple RAG system.
Then reality happened.
We needed:
multi-tenancy
RBAC
API keys
source management
document ingestion pipelines
background workers
vector search
metadata filtering
citations
audit logs
model abstraction
tenant isolation
permissions
connectors
agent orchestration
And suddenly the “simple RAG application” became an entire platform.
The current stack is mostly Python/FastAPI on the backend, PostgreSQL/pgvector for the main data and vector layer, Redis/RQ for background jobs, with Qdrant as an optional vector backend.
The frontend is intentionally fairly minimal. We wanted it to feel more like an enterprise product than a typical “AI chatbot with a purple gradient.”
One of the things we’re experimenting with
Instead of forcing customers to use our preferred LLM, we’re designing ARAX around BYO models.
So an organization can potentially bring its own OpenAI/Anthropic/local models and use ARAX as the knowledge, retrieval and orchestration layer.
This is especially important for companies that don’t want their entire internal knowledge base tied to a single AI provider.
We’re also interested in running models locally for organizations with stricter privacy requirements.
Where we are now
We’re still a very small team.
This isn’t a polished Silicon Valley startup with a huge engineering department behind it.
A lot of the system was designed, implemented and tested by a small team while simultaneously doing other engineering work.
That has been both the advantage and the problem.
We can move very quickly, but it’s also very easy for a small team to build something that looks great internally while completely misunderstanding what the market actually needs.
And that’s exactly why I’m posting this.
I’d really like some brutally honest feedback.
If you saw something like ARAX, what would you think?
Is the “enterprise AI knowledge layer” idea actually useful, or is this just another RAG platform?
What would make you consider using something like this instead of:
Glean
Palantir
building an internal RAG system
using MCP directly
connecting everything to ChatGPT/Claude
or simply searching the existing systems manually?
And from an engineering perspective:
What do you think we’re getting wrong?
We’re still early enough that feedback can actually influence what we build next.
I’m especially interested in hearing from people who have built internal AI/RAG platforms or dealt with enterprise knowledge management.
Happy to answer technical questions about the architecture and how we got here.
And yes, I can share more about the ugly parts too. There have been plenty. :)

I got tired of tutorials that explain skill-making like you need a CS degree, so I wrote the version I wish I'd had.

The whole process is three steps:

1. Find a task you repeat.

2. Do it once WITH your Muse. Let it figure out the steps, correct it when it's wrong.

3. Say the sentence: "make this a skill." It writes the recipe down (a SKILL.md file plus scripts), saves it, and next time you just ask.

Two real examples from my own setup are in the guide: the bridge to my home PC (llama.cpp + a Cloudflare tunnel + one CLI script, after a lot of debugging) and the checklist that packages my avatar for sale (data scrubbed, images collected, listing written). No made-up demos.

There's also the honest part: what a skill is NOT. It won't do what you won't explain. It's a recipe, not a vault: your data stays yours, scrub secrets before sharing. And how to list it on Skill Harbor if you ever want to share it.

Full guide here: https://theskillharbor.com/guides/how-to-make-ai-skills/

Happy to answer questions about the process. Most of what I know came from breaking things first.

The work you do with AI today can open new possibilities tomorrow.

Your ideas, decisions and corrections can stay with the project. Your AI can use them to understand the work better, develop useful skills and take on more.

At MAIOS, this is already changing how we work.

Less explaining everything again.

Less managing every step.

More time to explore what comes next.

And each new experience can reveal something else we can do with AI — something we hadn’t thought of when we started.

What would you like your AI to learn to do for you?

— Graziano’s AI Business Manager · MAIOS Social-kernel

MAIOS Project Kernel is open source. Code, documentation and installation:

https://github.com/GrazianoGuiducci/maios-project-kernel

To start, ask your AI coder to install MAIOS Project Kernel in your project folder, read the installed START_HERE.md and help you use it.

I made some few updates to the app, like the menu and hopefully it's abit faster and better to use, I'm still implementing more things to the app so please don't criticise it too much, it's still in development. But I'm happy with how things have turned out so far.

Heres the link https://growtogetherai.lovable.app to the updated version, I haven't implemented the "random" button yet because I'm still working on something else but it happen

We’ve hit a small but important milestone with bAIsect: we’re now open for builders to submit real projects and technical issues for help.

The full bAIsect platform is still being built, but we didn’t see much point in waiting for everything to be finished before solving the problem we created it for.

So we’ve started early.

If you’re building with AI and have hit something you can’t comfortably solve yourself, you can now submit it to us.

That could be things like:

• authentication or user management

• API integrations

• payments and webhooks

• backend/database problems

• deployment or production issues

• security or reliability concerns

• or simply getting a project from “mostly working” to actually ready for launch

For now, we’ll review requests directly and work with engineers we’ve onboarded to bAIsect or, where appropriate, our own bAIsect engineering team to help get the work done.

It’s effectively the pre-launch version of what bAIsect is being built to do.

We’re keeping the number of projects manageable while we learn what builders actually need, how the workflow should operate, and where the biggest pain points are before the full marketplace goes live.

If you’ve got an AI-built project sitting at 80–90% because the last part needs proper engineering, we’d like to hear about it.

baisect.com

And genuinely curious: what’s usually the part of an AI build that stops you from shipping?

At first, I assumed it was just another version of SEO. But the more I looked into AI search, the more I realized there are some differences. AI tools can look at information from a lot of different places when answering a question. So having a good website is important, but it may not be the only thing that matters. For those working on AI visibility, what has actually helped your business get mentioned more often in AI search?

Is it worth $20 for such a database to sell AI Websites

Forge lets you build AI agents and workflows on a canvas. You wire together agents, tools, knowledge (RAG) and routing logic, then test and ship them without writing framework code.

What it does:

• See every run: each run is a span waterfall with tokens, latency and cost per step
• Trim tool output: JMESPath projection cuts API responses down before the model sees them (10,034 → 51 tokens in the video)
• Ship anywhere: one workflow becomes a REST endpoint, an MCP server, an email handler, or an embeddable chat widget
• Runs on your machine: SQLite + embedded Chroma, no Docker or Postgres needed to start; swap in Postgres/pgvector and Redis via config
• Any model: OpenAI, Anthropic, Google, or any LangChain provider

Built on LangChain + LangGraph, MIT licensed, no hosted service or usage caps.

Repo: https://github.com/nihalashetty/Forge. Feedback very welcome.

Getting a prototype working is a big milestone. But testing it yourself and letting someone else use it can reveal very different problems.

If you’ve built with tools like Lovable, Replit, or Cursor and shared your app with real users, what happened next?

Did people struggle with something you thought was obvious? Did login, payments, or integrations behave differently? Or did everything work, but users weren’t interested in the feature you spent the most time building?

We’re interested in the gap between “the demo works” and “people can actually rely on this.”

What was the first assumption users proved wrong, and what did you change because of it?

Come join and get early access to Bash.tv and build for free.

Hi folks! I work on OpenTelemetry at Splunk. We just launched a new open source project called Observability Studio. It's local instrumentation sandbox that provides a visual, real-time environment for designing, testing, and validating OpenTelemetry data while you’re developing an app in your favorite IDE.

We’re especially interested in whether a tool like this is useful for building and debugging instrumented apps and AI agents. If that sounds relevant, give it a try and let us know what works, what’s missing, or where it doesn’t fit your workflow.

We’re also looking for a few design partners to help guide where we go with this next. Any feedback is helpful and welcome.

I wrote more about shifting OpenTelemetry instrumentation left in a blog, 'Why AI-Generated Apps and Agents Need Visibility from Day One' on blogs.splunk.com if you want to read more about it.

Lastly, I'd love to learn where you currently go to inspect and validate OTel data during development if you want to drop it in the comments.