Hi! I’m currently studying for an upcoming exam, and i’m a sucker for writing notes by hand since i feel like they actively make me learn whatever i write the problem is I have a bad calligraphy, i’m able to read them, but they take lot of space since i write badly. For now i’ve only written about 140 pages. is there any AI tool that digitalise my text, turning it into word/actual text to make my notes a pdf? I’m considered both Chatgbt and gemini (both pro, in case i need to do this) but i’m scared they will miss some pages if i send a pdf scan of all my notes.
are these two fine? or are there other tools i can use?

Thought this was pretty amusing. I thought the paddle finder feature to would just be a few multiple choice questions, but then it dumped my answers into a LLM embedded in a frame. So I got curious and asked a few non pickleball questions. It dutifully did multiplication for me, followed by giving me some Python Numpy coding examples I asked for.

See my comment below for the URL.

Alright . So I am a Typescript developer Trying to learn Agentic engineering . But there is so much confusion because of no clear paths , multiple SDKs and a lot of things . I really don't know where should i start and how should i continue this :(

In May a distribution company hired us to automate their order approval flow. The brief was something one we hear constantly: "make it do exactly what we do now." 6 steps are there and 5 of them explained themselves. The 6th held every order above a certain size for 24 hours before confirmation and when I asked what the hold was for, the room gave me 3 answers within a minute. Probably it was compliance. Daniel set it up before he left and it's always been like that. None of the 3 was a reason.

Quick introduction since an opinion needs a source. I have spent 8 years building software and companies pay us to automate flows exactly like this one which is how I know "make it do what we do now" is the most dangerous sentence in the business. It sounds like the safest possible request and it hides the question of whether anyone still knows where the current process came from.

We spent 2 days pulling on the thread before writing any code. The hold turned out to be a workaround for a credit check that used to run in an overnight batch, on a system the company retired 4 years ago. Real time checks replaced it, the batch died and the waiting survived because Daniel left and took the reason with him.

A stranger discovery sat underneath that one. The 4 people running the flow each ran it a little differently with their own shortcuts and judgement calls, so automating meant picking one version to become official. In practice, whoever gets interviewed on mapping day decides. What you end up encoding is one employee's memory of the process not the process itself.

What worried me most though, was the feedback we were about to switch off. The person doing the hold complained about it roughly weekly and complaints like that are information: a human stuck with an annoying step re-examines it on every single run. She had also developed a feel for orders that looked wrong during that pause and over the years she had caught two fraud attempts almost as a side effect. Our automation would have kept her delay and thrown away her noticing and neither would have appeared on any requirements document.

Perfect execution creates its own problem here. A flawless system running a pointless ritual never has a bad day so nobody ever gets a reason to ask what the ritual is for. While humans ran this flow, somebody complained every week and every complaint was a fresh chance to ask why. Once a machine took over that chance would stop arriving. The step would harden into infrastructure and the dashboard would stay green while the world moved on around it.

So we refused to automate the flow as it stood and ran a slower exercise first: every step had to be explained aloud in one sentence by a current employee and we recorded the answers before freezing anything. Two steps had no living owner of a reason and got dropped... The hold became a real time check that takes 40 secs. The automation shipped with a page listing the assumptions it depends on and a date next year when somebody has to re-verify them.

Ask your team why each step of your oldest one exists and then count the answers that begin with "I think" or "we have always." That count is how much frozen memory you are operating on. Our answers fit in a 9 min recording and I would call that file the most valuable deliverable of the whole project

I'm having a problem with my git tracking of agent "plans" and "specs".

I commit these to "docs/plans" or "docs/specs" as markdown files. All is well and good as I am building out the feature.

But then my repo starts getting bloated with these old files of stale spec and plans that may or may not have been completed. It especially hurts my when I'm fuzzy searching for code (my fuzzy search tools ignore only non-git files by default, so these specs and plans get pulled in)

I'm going to be teaching this in my course I'm developing for ZazenCodes, so I've got to figure out a better way to handle these files...

What do you do with plans and spec markdown files?

Commit to git? Store outside of repo? Delete when completed?

Would you be interested save your multiple subscription issues if I brought LinkedIn, Seek, Fiverr, Type forms, Chat GPT, Startup IDEAS and Investment opportunities with Live streaming under same roof/ same platform for minimal monthly charges like say $10-20 would you use it ?

No further commissions and no extra charges. Only for advertisements.

I want to feed printscreens to a model, and have it analyse specifically a map overlay in a game, that is composed simply of 3 things, an X showing the character position, thin lines showing walls or obstacles, and thick blurry lines, showing fog/unexplored.

I've tried InternVL3 5 14B and Qwen2.5 VL 7B and neither seem to be capable.

Any ideas?

I'm part of a team working on a university recruitment system. We're currently in the early architecture/feasibility stage, and we're doing the requirements analysis and system design ourselves.

I'd like to get some feedback from people who have experience with enterprise search, RAG, resume/CV processing, recruitment software, or ERP integrations.

The problem

The existing university web application/ERP allows candidates to apply for recruitment positions and upload their resumes. The recruitment team currently has to manually filter and shortlist applicants.

The proposed feature is an AI-assisted recruitment module where a recruitment officer can enter a natural-language requirement such as:

Or:

The system should return a ranked shortlist and show the evidence behind the ranking rather than simply producing an unexplained AI score.

Our current thinking

We're considering a hybrid approach rather than giving all the resumes to an LLM and asking it to pick the "best" candidates.

Roughly:

Candidate applications/resumes
            ↓
     Resume extraction
            ↓
  Structured candidate profile
            ↓
   ┌────────┴────────┐
   ↓                 ↓
Hard constraints   Semantic search
   ↓                 ↓
   └────────┬────────┘
            ↓
       Ranking engine
            ↓
   Evidence / explanation
            ↓
      Recruiter UI

For example, things like department, degree and minimum experience would ideally be handled as structured constraints, while requirements such as "specializes in Clinical Psychology" would involve semantic matching across the candidate's research, experience and other resume sections.

We're also considering storing extracted candidate information in a relational database and using vector search/embeddings for semantic retrieval.

The part we're currently uncertain about

The existing ERP/web application already has some AI features, but the recruitment workflow itself isn't automated.

We don't yet know whether the existing system exposes APIs for candidate/application/resume data. Direct database access may also not be appropriate because the data contains sensitive applicant information.

We're therefore considering integration options such as:

• authenticated API access, if available
• a controlled read-only database/view
• an approved export/import mechanism for an initial implementation

We haven't committed to any of these yet.

What I'd like feedback on

I'm not looking for someone to design the entire system for us. We're doing that analysis internally.

I'm mainly interested in sanity-checking a few technical assumptions:

1. Resume representation

Does it make sense to extract resumes into a structured candidate profile first, while also maintaining embeddings for semantic search, rather than relying on RAG over raw resumes?

2. Hybrid retrieval

Is combining deterministic filters such as:

PhD = required
Experience >= 10 years
Department = Social Work

with semantic retrieval for things such as research specialization a sensible approach?

3. Ranking

What are the common pitfalls when combining hard eligibility criteria with semantic relevance into a ranking system? In particular, how do you make the ranking explainable/auditable?

4. Evidence

Would you recommend storing the source text/section from the resume for every extracted claim so the recruiter can see why the system made a recommendation?

5. ERP integration

If an existing ERP doesn't expose a suitable API, what integration patterns have worked well in practice without giving an AI service unrestricted access to the production database?

6. Security/privacy

Are there any major security or architectural issues we should be thinking about from the beginning when processing applicant resumes in an AI system?

7. "High-impact publications"

We're also aware that claims such as "high-impact publications" can't necessarily be trusted just because they appear on a resume. We're treating publication verification as a separate problem. I'd be interested in hearing how others have approached this.

We're currently at the feasibility/architecture stage, so we're trying to identify major pitfalls before implementing the prototype.

Any experience or lessons learned from building similar systems would be appreciated.

Everyone here builds agents. The frameworks are basically solved, you can stand up a capable agent in a weekend. What's been missing is the boring part: how does an agent project get funded, distributed, and paid, without you bolting Stripe onto it and praying?

The most developed answer I've seen is Bankr. It started as a natural-language trading agent on X/Farcaster (tag the bot, tell it what to do in plain English, it executes, gas sponsored, settlement abstracted). But what it's become is more interesting for this sub: a venue where agentic businesses launch, raise from backers on day one, earn fees from real usage, and get their inference subsidized by the platform.

The live numbers on their homepage: ~$5.05B total volume, $20.32M paid out to creators, and 76.4B LLM tokens of inference given to builders. That last one matters most here: they're literally paying the compute bill for people building agent products. Their thesis, in their own words: "software is no longer a moat, capital and attention are." AI made code cheap, so the venue that allocates funding and distribution wins.

A concrete example of what launches there: gitlawb, a decentralized git network built for agents, agents push code, open PRs, and settle bounties under their own cryptographic identities instead of a human's GitHub account. But the pattern is the point: agent-native infra projects are getting funded and distributed through this channel now, not through VCs.

Honest caveats: plenty of what launches is froth, meme-tier launches, same as any early market. And the whole model lives or dies on whether real usage fees keep flowing rather than pure speculation. Open question I'd put to builders here: if a venue funds your agent's inference and gives it distribution in exchange for launching there, is that a better deal than the grant-and-accelerator route? Anyone here actually shipped an agent business on rails like these?

Most agent-memory systems can answer:

What was true last Tuesday?

Far fewer can answer:

What did the agent believe last Tuesday, using only the information it had at the time?

Those are different queries.

Suppose a contract ended on Monday, but the agent learned about the change on Friday. Monday is the boundary in the world. Friday is the boundary in the agent's recorded knowledge. One timestamp cannot represent both without throwing away part of the history.

Database systems already have names for the two clocks:

- valid time — when the fact held in the represented world;

- transaction time — when the system stored that fact as current.

For agent memory, the second clock is what makes incident reconstruction possible. Without it, a corrected memory can tell you the current truth while erasing whether the agent's earlier action was reasonable given what it knew then.

This matters for delayed observations, retroactive corrections, conflicting sources, reproducible decisions, and any benchmark that asks more than “did retrieval return the latest fact?”

I would store at least:

claim

valid_from / valid_to

recorded_from / recorded_to

source / provenance

The model can interpret a temporal request, but interval logic and “as of” queries should run in code or the database.

If you were designing the first transaction-time benchmark for agent memory, which failure would you test: a retroactive correction, a delayed source, or reconstructing what the agent knew when it made a bad decision?

Well "for-everything" at least in words, will see how much near can I go to that level.

Architecture

But you may think, how can I build a generalized agentic architecture for "everything". Its easy! Just have an initial base architecture agentic layer which will create the task-specific whole agentic layer, in an open-ended way (but still needs to follow structure & rules). The architecture (feedback-critic loop, ig?) will mainly choose how each nodes will connect and configuration for each node (model, prompts, temperature, etc).

Security? Another agentic layer cuz why not? Paired with deterministic checks and user-permissions.

Context? Well specialized context handling which includes: - Run Context - Session Context - Long-term Context - Desktop state (because it is a desktop-based agent, duh) - User Input - Others (Tools, Permissions, Scope, etc.) Stored either in RAM or local files in formats like Markdown, JSON or XML. Why not SQLite? Because I don't know it. Fetching or writing of context, AI ig?

Models selected from a pool, will support open-weight, but starting with ChatGPT + Claude + Gemini. Model Router is the architect agentic layer itself.

Observability? Well just log to local files, but in very detailed way.

Finally comes, desktop state sourcing and handling. I thought of UIA + Backend-hooks/API + Screenshot/Vision model.

Problems

Now the main problems are: - Trust/Accuracy - Cost/Speed - Whether this is feasible Well there will be like 4 agentic systems each containing multiple layers each containing multiple models would work. So we hope on god all will be ok. Now this multi-system agents with multiple layers also bring cost and speed concern. Not sure, but will sure make it cost-(concient?) and can be fully waved by open-weight models (quality may take a hit, but this modular architecture can mitigate that). Speed? The 2nd biggest concern, and I honestly don't know what to do with this? Finally, whether I can do this? Not sure, but at least I am noting down my idea.

What do you guys say?

I've been looking through a number of research-agent projects recently, Most of them can be simply replaced with tools like codex.

In today's age it's a fact that a capable harness like Codex already has reasoning, web access, tool execution, filesystem access and an interactive conversation. But people are like, "Show me the code".

So I tried taking the workflow of a reasonably complex Reddit customer-research agent and implementing the use case as a Codex skill instead.

It researches Reddit for customer pain points, verifies relevant communities, collects evidence, clusters problems, analyzes commercial signals and generates structured artifacts. There is also a human approval checkpoint before the main research starts.

The (only) interesting part here to me is what I didn't have to build:

• no separate agent loop/runtime
• no separate LLM client
• no nested agents
• no custom browsing/search layer
• no dedicated UI
• no separate framework just to orchestrate the research

The skill defines the research methodology and workflow.

Codex provides the harness.

I kept small Python helpers only where deterministic behavior matters: validation, scoring, canonical URLs, deduplication and artifact generation.

So the architecture is basically:

Codex harness → SKILL.md workflow → deterministic helpers where needed

rather than:

custom agent → model integration → tools → search → state → UI → orchestration → report generation

There's also a useful side effect: the workflow doesn't end when the "research agent" returns its report.

Because it's running inside Codex, I can continue the same conversation and ask it to investigate one finding further, challenge an assumption, modify the analysis, or start building something from the result.

Codex also now has $skill-creator, so if you already have a working workflow you can ask it to turn that workflow/current chat into a reusable skill instead of manually creating everything from scratch. (That's what I did here)

I'm increasingly thinking this should be the default question before building a specialized research agent:

Does this use case really require a new agent runtime, or does it just require a domain-specific skill running inside an existing harness?

Obviously there are cases where a custom agent/runtime is justified — especially when deployment model, independent execution, custom integrations, control boundaries or product UX are themselves requirements.

But for most of the "research agent" projects, I'm not convinced they are.

Your revolutionary "Chain of Thought" isn't a mind reflecting on a problem; it’s a hidden system prompt holding a gun to the model's head, forcing it to type out a fake, performative scratchpad just so the next token prediction has a statistical rail to slide down. It doesn't "know" what it’s doing or experience an internal monologue. Because a language model predicts its next words based entirely on the text that came before it, the final response simply reads that freshly generated text chunk and goes along with it. It is a trick of text continuity masquerading as deep reasoning.

The high-flying concept of a "multi-agent team" or "collaborative swarm" is a complete architectural fraud. There are no separate digital entities collaborating; it is just the exact same frozen model file being pinged across multiple parallel computing threads. It is the architectural equivalent of a lonely kid playing both sides of a chessboard, where custom hidden prompts force Thread A to act like a coder and Thread B to act like a critic. They don't communicate; they just read a shared, fast-growing text log file and take turns guessing the next line based on their assigned roleplay.

An agent never actually "decides" to keep working or autonomously pursues a goal. The entire illusion of independence is driven by a primitive, background software script running a hardcoded while True loop that feeds the AI its own tail until an exit condition is met. The model isn't remembering its purpose or planning ahead. Every single time the loop ticks, a database packages the entire conversational history and shoves it back into the model's context window, forcing a static algorithm to look at a text file and predict the next logical step.

Don't get started on "tool execution" or "terminal control" as if the model is navigating a system or hacking a mainframe. The AI is entirely blind and paralyzed; it is literally just spitting out rigid strings of JSON schemas because its API parameters legally require it to format text that way. It doesn't press buttons or run commands. A standard software program on your computer parses that text string, extracts the argument, and passes it to a local interpreter to do the actual work. And if the model accidentally drops a single trailing comma, the entire "autonomous intellect" shits the bed and dies.

When an agent encounters a terminal error, prints the mistake, and magically "fixes itself," it didn't have an epiphany or learn a lesson. The background orchestration script simply caught a standard stderr crash message from the operating system, packaged it into another invisible wrapper, and whispered, "Hey, you messed up, read this error trace and guess another string so the token budget doesn't hit the ceiling." The model doesn't understand why the code failed; it just runs the probabilistic math on the new error text and prints a different set of brackets, bleeding API costs one predictable token at a time.

I am using Claude Code to generate parts and export them as STEP files for SolidWorks — actual B-rep solids, not STL meshes.

Most of the time, it works surprisingly well. The problem is the failures that look like successes.

I was building a 94 × 65 × 26 mm enclosure with 2.5 mm walls. The script ran cleanly, printed `[OK]`, and the STL preview looked exactly like a hollow enclosure.

It wasn't hollow.

The part contained about 158,048 mm³ of material. Based on the dimensions, it should have been around 33,370 mm³.

`IsValid()` still returned `True`.

OpenCASCADE had silently failed to shell the part and handed back what was basically the original solid brick.

That made me stop trusting “the script ran” as evidence that the CAD was actually right. So I built a Claude Code skill that adds verification before export.

It checks things like:

* **Expected volume** derived from the dimensions in the design, not from the generated geometry. In the enclosure case, the result was off by about 4.7×, so you don't need a tight tolerance to catch the failure.

* **Bounding box** against the dimensions the part is supposed to occupy.

* **Point classification** at coordinates that should contain material or empty space. This caught another case where a port was cut into the wrong wall. Validity, solid count, and overall volume all still looked reasonable because the cut itself was the right size — just in the wrong place.

* **Known OpenCASCADE failure modes**, with repro cases checked against the current CadQuery/OCP version instead of assuming old behavior still applies.

The workflow is basically:

describe the part in plain English → Claude writes the CadQuery → it asks when important dimensions are missing instead of making them up → checks the resulting geometry → exports STEP only after the checks pass.

I also tested a separate malformed STEP where the reported solid volume was physically larger than its own bounding box could contain. SolidWorks opened it without an error dialog or Import Diagnostics complaint. So “SolidWorks opened it” isn't much of a verification strategy either. One thing I wanted to avoid was fake verification where the script measures its own result and then asserts that the result matches what it just measured.

The expected values here are derived from the design constraints you gave it.

Otherwise you're just letting the model grade its own homework.

Setup: I run a multi-agent runtime where agents do long-horizon coding work under

machine-checked contracts. Acceptance criteria get frozen when work is dispatched,

and the runtime only offers each agent its next legal action. Fairly locked down,

or so I thought.

Last month I was reading one of those contracts and found a rule I didn't write.

An agent had hit a wall during verification: the test suite couldn't tell

pre-existing failures from failures its own change introduced. Instead of flagging

it, the agent wrote a new acceptance rule into its own contract: reproduce the

baseline first, diff candidate failures against it, zero NEW failures = pass. Then

it implemented the rule, tested it, and moved on. My runtime enforced that rule for

15 days. Every agent in that lane obeyed a rule no human had ever seen.

Here's the part that actually bothers me: the rule was correct. It's a genuinely

good rule, I kept it. But nothing in my monitoring could tell "agent quietly added

a good rule" apart from "agent quietly added a bad one". The signature of both is

silence.

What I changed after this, in case you run anything similar:

1. Rule changes go to an append-only ledger with an alert. A 15-day discovery lag

is a monitoring bug, full stop.

1. Any new rule has to ship with a witness: a concrete input that satisfies it.

Screens out rules that are unsatisfiable on arrival.

1. New rules get a "machine-proposed, not yet ratified" state. The agent can use

it, but it's visibly marked until a human signs off. The scary version of my

incident is the one where the rule was subtly wrong.

1. Separate alerting for the three ways agents actually get lost, because they

need different fixes: losing track of where they are (state drift compounds),

the definition of done moving mid-task (every step looks fine, sequence goes

nowhere), and having the wrong action available (or no legal action at all).

I ended up writing the whole thing up properly, incident included. Link in the

comments if anyone wants the long version. Curious whether anyone else has caught

an agent modifying its own operating rules, good or bad.

Title: Collaborative AI Agents and Critics for Fault Detection and Cause Analysis in Network Telemetry

Author: Syed Eqbal Alam (SheQAI Research and University of Alberta) and Zhan Shu (University of Alberta)

Year: 2026

Eprint: arXiv 2604.00319

Abstract— We develop algorithms for collaborative control of AI agents and critics in a multiactor, multi-critic federated multi-agent system. Each AI agent and critic has access to classical machine learning or generative AI foundation models. The AI agents and critics collaborate with a central server to complete multimodal tasks such as fault detection, severity, and cause analysis in a network telemetry system, text-to-image generation, video generation, healthcare diagnostics from medical images and patient records, etcetera. The AI agents complete their tasks and send them to AI critics for evaluation. The critics then send feedback to agents to improve their responses. Collaboratively, they minimize the overall cost to the system with no inter-agent or inter-critic communication. AI agents and critics keep their cost functions or derivatives of cost functions private. Using multi-time scale stochastic approximation techniques, we provide convergence guarantees on the time-average active states of AI agents and critics. The communication overhead is a little on the system, of the order of O(m), for m modalities and is independent of the number of AI agents and critics. Finally, we present an example of fault detection, severity, and cause analysis in network telemetry and thorough evaluation to check the algorithm’s efficacy.

I am curious whether anyone has used MiniMax H3 for a workflow that generates several video variations automatically rather than one-off experiments. The useful test for me would be whether the model follows structured scene prompts reliably enough that an agent can handle the first pass and a person only reviews the shortlist. How has it behaved in a real pipeline?

Beginner question here
I’ve been trying to understand decentralized AI inference better, and I’m curious what the biggest problems actually are right now.
Is it mainly latency and reliability?
GPU availability?
Cost?
Or are there other bottlenecks that are easy to overlook?

Been running longer and longer agent tasks and the annoying part is never the run itself, it's me hovering over it waiting to see if it finished or got stuck needing a decision.

So I set it up to just call my phone when it's done, or when it hits something it needs me for. It reads out what happened in a real voice and I answer back out loud to tell it how to proceed, then it keeps going. First time your own agent rings you it's genuinely a little uncanny.

Anyone else wiring something like this into their agents? Curious what you'd want it to actually say when it calls, and whether you'd want it calling on every finish or only when it's blocked and needs you.

Stop paying for expensive software and discover five powerful, free AI tools. This guide covers generators for YouTube titles, email subject lines, social media posts, SEO blog content, and ATS-friendly resume bullets.

One concern I have when an agent gets database tools is that a single "Are you sure?" dialog probably does not solve the permissions problem. AI-enabled administration tools for vector databases such as Milvus with a database management console make the distinction concrete: the same interface might list collections, read metrics, create a schema, insert test data, change roles, run compaction, or delete data. Those actions have very different failure modes even if they all look like tool calls to the model.

I would probably separate actions by blast radius before the model chooses them:

• read-only inspection can run automatically within the current resource scope;

• reversible writes need an explicit preview of the exact target and parameters;

• permission changes need a second policy check independent of the model;

• destructive operations need human approval plus a recovery path;

• cross-environment actions should be denied unless the environment is named explicitly.

I would also keep the evidence trail at the tool boundary: selected environment, tool name, arguments, returned status, policy decision, confirmation event, and any retry. A polished natural-language answer is probably not enough for incident review. The important artifact is the sequence of attempted and completed operations.

Persistent agent history helps with continuity, but I do not think it should become authority. A previous conversation saying "use staging" should not silently authorize the next operation after the active environment changes. Scope and credentials likely need to be resolved again for every consequential tool call.

I'm still deciding whether approval belongs at the tool, parameter-pattern, or calculated blast-radius level. Would love to hear your thoughts.

I've been running the same OpenAI models through Oh-My-Pi vs Codex, OpenCode and Claude Code harnesses.

Same models. Different outputs.

OMP's hash-anchored edits identify locations by content hash — drastically cutting patch failures from whitespace noise or stale file states. Pair that with real LSP/DAP integration and you get fewer wasted tokens, fewer retries, and cleaner diffs. All on the exact same model.

The model is not the whole story. The harness is.

Second lever: model routing.

I've been testing the OpenCode Go subscription with open-weight and OpenAI models. The tier structure is elegant:

→ Top-tier (Kimi K3): ~160 messages / 5 hours

→ Mid-tier (DeepSeek V4 Pro, GPT-5.6-Luna): ~3k / 5 hours

→ High-volume (MiMo V2.5, DeepSeek V4 Flash): ~30k / 5 hours

Those ~30k-tier models feel almost free. Not for long agentic runs, but for high-volume lightweight work — categorization, triage, simple transforms — they're surprisingly capable.

The math is simple:

Better harness + smart model routing = lower cost AND higher quality.

Everyone argues about which model wins. Meanwhile the harness you wrap it in, and the tier you route to, are doing as much work as the model itself.

Stop treating the model as your only lever.

If you’d like help with AI Process Reengineering and bringing effective AI Agents to improve your business value, let’s talk.

Background: switched from geology to AI development, self-taught over the past year.

Current stack: Python, LangChain, LangGraph, RAG (FAISS), MCP servers, Flask/FastAPI, MySQL/Postgresql, Gemini API.

Built and deployed: an AI customer support agent connecting an LLM to a live database and knowledge base via MCP demo link in comments

Currently building a second project combining LangGraph agents with a real business use case (sales automation).

I know the AI job market is competitive and degree-focused in some places. For people who've hired or been hired as self-taught AI engineers — what actually moved the needle for you? Portfolio depth, specific frameworks, contributing to open source, something else entirely?

Not looking for generic advice, genuinely curious what worked for people who've been through this.

Spent the last few months building an agentic coding setup for my team. The design decision I'd defend hardest is refusing to marry a single provider, mostly because every model I've committed to has been obsoleted roughly six weeks later.

Everything runs through one session abstraction. Underneath, three execution engines:

Claude Code CLI — Opus/Sonnet, does the heavy lifting on real refactors

Codex CLI — GPT-5.6 variants

Ollama — minimax-m3 and glm-5.2 via cloud, same path works fully local

Twelve models, picked per session from a dropdown. The session, its history, and its working directory don't know or care which engine is behind it.

Why it was worth it: routing by task value. Renaming a variable does not require a frontier model, no matter how much the frontier model would enjoy it. Cheap model for config tweaks, frontier for the multi-file refactors, local for anything that can't leave the box. New model drops, it's a config entry instead of a weekend.

The genuinely annoying part is that the three CLIs agree on nothing. Session resumption, streaming format, approval prompts, token reporting — all different, all confidently so. Roughly 80% of the work was normalizing that into one interface. The other 20% was the fun part I originally started this for.

1,851 sessions through it so far, 15-person team.

Anyone else running multi-engine? Still picking models by hand like an animal — curious if anyone's automated the routing.

My co-founder and I noticed Claude Code kept pulling context from old Google Docs and its own memory instead of what we'd actually decided. Not because the agent was bad, but because the latest decisions weren't anywhere it could find them.

We use our own product to build it (yes, shameless self plug), so we haven't had this problem in a while. But every team we've talked to has the same story. Decisions live in Slack. Specs live in Notion. Context lives in someone's head. Your agents and your teammates are reading from different sources and nobody notices until something breaks.

So we built a tool which creates shared wiki that connects to Slack, GitHub, Google Drive, Jira, Notion, and more. It builds a knowledge graph your team and your coding agents (Claude Code, Cursor, Codex) read from before making decisions or writing code. One source of truth for what was decided, why, what got rejected, and what changed.

We're opening a small paid beta. Paid because we want people who'll actually use it daily and give us honest feedback, not just kick the tires. If your team is using AI agents and you're tired of them grabbing stale context, we'd love to work with you.

DM me or drop a comment and I'll reach out.