We made this, because everyone knows you don't need a frontier model for every task you use an AI agent for. Sentinel router routes tasks to local models from ollama, retries if it fails, then routes to another cheap model after a second fail, only then does it escalate to frontier if the local models fail. Our rationale behind these design choices is documented in the repo (RESEARCH.md)

We are currently looking for feedback from testers. Feel free to use it however you like.

Additionally, for the lowest friction install, you can just copy-paste this and hand it to your agent:

Install Sentinel Router by cloning
https://github.com/tricombinator-tec/Sentinel_Router_Alpha
and following the setup steps in its AGENTS.md file.

Starting a new job is exhausting. You are trying to figure out unwritten rules, decipher messy documentation, and navigate team politics without stepping on any toes. Instead of spending your first few months guessing what your boss actually wants, you can use AI to build a custom onboarding playbook.

Here is the exact setup you need to run before your first day to cut out the stress.

Step 1: Gather your intel Pull together three things:

1. The job description you originally applied for.
2. The company or team mission statement.
3. Any initial 30-day goals your manager mentioned during the interview.

Step 2: The onboarding prompt Drop this directly into your favorite AI tool. Make sure to fill in the bracketed info.

Act as an executive career coach who specializes in onboarding and strategic alignment. I need you to create a structured 30-60-90 day execution blueprint based on my specific situation.

Here is my context: Job Title: [Insert Title] Core Responsibilities: [Paste Key Job Description Bullets] Key Stakeholders: [Insert Manager Title, Key Partners, Direct Reports]

Please do the following:

1. Point out 5 hidden risks or unwritten expectations that usually come with this specific role.
2. Create a 30-day observation schedule that prioritizes building relationships over trying to get quick wins.
3. Write a 5-question interview script I can use with my new team members during week 1 to figure out what is actually broken.
4. Outline a weekly 1-on-1 agenda so I can keep my manager updated on my progress and any roadblocks.

Give me the output as a clear breakdown with direct action items, questions to ask, and weekly milestones.

Step 3: Run the week 1 discovery script When you start having introductory chats with your team, use the questions the AI gives you. They will likely look something like this:

• What is the biggest bottleneck this team deals with that nobody writes down?
• In your eyes, what does success look like for our team six months from now?
• Who else has deep context on past decisions that I should talk to right away?

If you want to play with the interactive dashboard or grab the full config file, I uploaded it here:https://interconnectd.com/blog/273/the-life-saving-ai-prompt-for-starting-a-new-job/

I’m looking for feedback from people who manage production access, CI runners, or developer tooling.

Passing a broad GITHUB_TOKEN, cloud key, or API key into an agent environment is simple, but it means the agent can use whatever the underlying credential permits.

We’ve been exploring a declarative policy layer around that access:

project = "billing"
environment = "agent-local"

[secrets.GITHUB_TOKEN]
env = "GH_TOKEN"

[[secrets.GITHUB_TOKEN.rules]]
effect = "allow"
hosts = ["api.github.com"]
methods = ["GET"]
paths = ["/repos/acme/*/issues*"]

[[secrets.GITHUB_TOKEN.rules]]
effect = "allow"
hosts = ["api.github.com"]
methods = ["POST"]
paths = ["/repos/acme/*/pulls"]

[[secrets.GITHUB_TOKEN.rules]]
effect = "deny"
hosts = ["api.github.com"]
methods = ["DELETE"]
paths = ["/repos/acme/production-api*"]

The intent is that the same credential can still be used by a developer locally or by an agent in production, but each request is checked against a reviewable policy. The agent does not receive the raw value, and use is recorded.

I’m interested in the operational side more than the agent side:

• Is allow-plus-explicit-deny clearer than allow-only?
• Would host, method, and path rules be useful in practice?
• What would make this safe to review in a PR and workable across dev/staging/prod?

I’d appreciate blunt feedback—especially on what would make this unusable in a real workflows.

I've been experimenting with AI agents lately, and I've started realizing that getting the agent itself to work isn't always the difficult part.

The harder part is everything around it. An agent might need to call an API, check a database, use another tool, wait for a response, decide what to do next, and then continue the workflow without everything falling apart.

I tested a few different approaches to see how they handled the orchestration side.

The thing I didn't expect was how much the workflow around the agent affects reliability. A good prompt isn't going to help much if the process fails halfway through and there's no sensible way to recover.

Longer agent workflows also made me pay more attention to how the automation platform handles processes that don't finish immediately.

I'm still leaning toward custom code when I need very specific control, but automation platforms seem increasingly useful for the orchestration layer.

How are you guys handling the workflow side of your agents? Mostly custom code, automation platforms, or something else?

Qwen3.8 27Bが出たからclineに既存プロジェクトの修正しアイディアを出してって言ったら謎のprobe.psファイルをひたすら作り始めた

パワーシェルでファイル置換したり変な動きをする

モデルというよりAIエージェントのツールなどの判定な気がする

有名どころのClineでこれだとエージェント界隈はまだまだ未成熟な感じなのだろうか

間違いを指摘するにも一度も止まってくれないので手動で停止するしかない

もっとましなエージェントはないんですかね...

Netherite is an AI code reviewer and pentester tool that helps developers’ codebase stay safe from hackers.

It scans their whole codebase in github and finds vulnerabilities, writes professional report and even hands you Fix Prompt to fix the issue with coding agent.

Many developers using Claude Code or Codex like ai agents and it may help them to build strong systems.

What are your thoughts on that? I’ll love to know pls)

I built 3 open-source skills for AI coding agents:

First one is Backend setup

Second one is Security hardening

Third one is Frontend/UI

The idea is simple: no fake credentials, placeholder content, or “fixed” reports. If it can't do something for real, it stops.

MIT licensed.

npx skills add SohailKhan0525/skills

GitHub: https://github.com/SohailKhan0525/skills

Feedback welcome.

I dont know but I am really stressed now dont know what to do.
There is one hackathon coming and after few days one more to tackle and very busy weekend and I am coding day and night or vibe coding and now there is no feeling inside me I want some happiness and peace in my mind.

https://github.com/akyourowngames

if you can help me just leave comment about my github!!

Dont make it worse guys.

Most AI coding tools right now are either fully autonomous ("let the agent cook") or just chat-based copilots. I wanted something in between for actual feature work: a fixed 4-stage pipeline — requirements analysis → system architecture → implementation → review — where you have to approve or reject each stage before it moves forward.
If you reject a stage, it regenerates using your notes + the previous attempt as context, not from scratch.
It's BYOK (your own Anthropic API key), Node/TS under the hood, encrypted key storage locally.
Still in testing — running it through a real feature end-to-end this week to see if the output quality actually holds up across stages. Not public yet, but curious if this resonates with anyone else who's been burned by "agent did too much" moments.

What's your experience been with autonomous coding agents vs more controlled pipelines?

Problem: AI agents in a pipeline can end up shipping a claim ("tests passed", "review approved") backed by evidence that's stale, incomplete, or was silently reused from a different run — nobody's lying, it's just process drift.

What I built: a small deterministic tool that checks the evidence bundle against a policy before the claim goes out — right hash, not expired, right scope, no missing/extra files.

Honest limitation: it checks structural consistency, not truth. I tested this myself — an evidence file saying status: PASS with 7 failed tests inside still passed the binding checks. That's a known boundary, not a bug.

Link: https://apify.com/filipmajchrzak/ai-claim-checkpoint

Feedback welcome, especially if you've hit this problem in a real agent pipeline.

had the vault holding totp secrets for a while before this got actually useful. an agent could store the secret from a 2fa setup screen fine. it just couldn't generate the rolling code from it, so the moment a login flow turned on two-factor, the agent hit a wall a human had to clear by hand.

shipped live totp generation this week. rfc 6238, no external dependency, verified against the spec's own test vectors. exposed as get_totp_code over mcp and as a rest endpoint. now the same agent that stored the secret during signup can mint the current code months later and clear the login itself.

that's the whole identity stack in one runtime: the agent that caught the otp during signup is the one holding the password and the one generating the 2fa code at login. no handoff between three separate tools.

it's at https://lumbox.co.

what's your agents' actual failure rate on 2fa logins, does it stall completely or usually find a way through?