ksajadi

i find the best way to think about this (and build around it) is to think how we as humans learn by doing: we have an idea of what to do (plan), then do, and then learn from what we did (right or wrong). you can also extend this to the entire team/company through what's usually called "institutional knowledge".

here is how i approach it in practice:

i've seen many try to generalize rules before doing things (design principles, guidelines, architecture,...) but often the best way is to start small, guide the agent step by step and (this is the most important part) at the end ask the agent to summarize what it learned and write it down.

then on the next cycle, ask the agent to read the previous notes and do this again: read, do, write.

i've been doing this for about 14 months now and have ended up with 2 categories of "knowledge": general (runs across multiple projects) and specific (per project).

these are kept in two formats: markdown and "decision records". each decision is a markdown but has meta data around its state: approved, rejected, failed, etc.

this growing body of knowledge works very similar to experience.

one note about agent memory: first i find it opaque, secondly not sharable across team members, and thirdly not very human friendly (basically as the agent does more, you learn less about your own project due to the opacity of the memory).

one thing i haven't been able to do figure out well yet is how to extract this from an existing codebase into this structured library of markdown and decisions. i'm keen to see how others do this.

once you have this library, you can get your agents to respond to inbound signals (slack, sentry, axiom alerts, etc) and work with a high level of quality and confidence, provided that they follow the read, do, write cycle EVERY TIME.

when i started this system, i used a committed markdown in git, then moved it to an obsidian (with MCP), then to Notion (so it's available team-wide) and finally built a product around it (bench47.com, if you care to check it out, disclosures, etc)

how is this different from anthropic srt?

i wonder if there is a chain reaction point, when one compromised vendor holds secrets to another one and that becomes the next target. Northflank lists Sentry as their customer. So if Northflank secrets are decrypted and Sentry used them for deployment, you have a starting point to attack Sentry next which then opens up a lot more.

cool idea (it's very similar to sendops) but why wraps? what's the deal with that name?

Isn’t it a little like asking a PE or VC: “if you’re so good at investing, why don’t you invest your own money”?

There are some money managers that don’t take in external money (I think TwoSigma started that way). Which could mean there might be someone out there that just does crazy good apps with their own model and don’t sell the model in form of tokens. We can’t know that by definition but the maths of tokens suggests that’d be very unlikely to exist at least right now.

Secondly, I think they are doing that. All the functions that their harnesses take on are businesses they are taking money from. It’s just not in the form of SaaS as we know it.

looks cool. how's that different from things like markbase dispatch where you can fire up the agent remotely with some given context. i mean what is the advantage of having the agent run always vs start and stop when you need it but give it a long-term memory context? maybe i'm missing something.

someone managed to get the environment variables AND the encryption keys for those? i feel for the secops engineers over there right now. brutal

The first thing I look at the next time I look at a project like Deno would be its governance structure and if it can be bought by a large company. Imagine if what happened here (or MySQL) happens to Postgres!

My girlfriend just got scammed by a super convincing ad for UK Visa which looks identical to the real thing.

I have no idea how you can get that wording and that landing page get passed the google review.

I’ve done a lot of ads on google and every time my ad was just a little off (use of trademark word or competitor’s name with a reserved keyword) it will be blocked.

Reddit is probably the worst of these ad platforms. We had a simple issue: we couldn't set the account that the ad was coming from to be the correct one (we have two Reddit accounts). That's it! So we sent a support email.

That was the beginning of 4, 45 mins sales calls, with full Powerpoint decks and on the spot commitments from us to reach, spend, etc. At the end of each call the rep would promise us that the account issue is escalated and will be fixed before we launch the campaign and would set the time for the next call.

3 weeks in, the account issue is still not fixed and frankly I cannot trust anything they say about their metrics, impressions, CTR or anything else.

Maybe I’ve just been unlucky for 14 years but ads almost never work (as much as you pay for them).

Ad business is the best business: you pay for something no one can reliably verify or measure. But you still pay because there is something somewhere with some correlational relationship with an uplift in some of your metrics and you’re afraid to turn it off. So you just keep paying.

If you login to the admin side of any ad business (Reddit Ads, X Ads, LinkedIn Ads etc) you are faced with a severely broken product: broken buttons, obviously wrong metrics, and other glaring bugs.

But somehow you still trust that people who cannot pull the CRUD side of the product off, are going to serve your ad accurately to the targeted audience and give you reports.

To me this is where the EU MEPs should place their privacy concerns. Unless it ends up being another consent pop up on TVs.

looks very similar to markbase.cloud

But it will remove the load bearing seams for the three things it might want to highlight before the gate is open.

Totally agree. However I am hopeful. We started the first full instrumented project a few years back. It took us a long time to do the whole work including understanding the SDK, mapping the dimensions and getting everything right. Our last project we did the whole thing with agents and they really took away a lot of the pain from the implementation part. We also use Axiom MCP so when we need some trace or event in the logs the agents look for it and if they don’t find it they’ll add it for the next time. It’s really been a different experience.

How do you stop agents from working over the same document at the same time? We do markbase for this exact reason.

i just wish google cloud ux was remotely as good as their models. they made some progress with their studio, but then in a true google fashion, product names keep changing (Gemini, Anti-gravity, Vertex, Google AI,...) as well as confusion and complexity for something as simple as registering agy cli with a Google cloud project.

today i wanted to link agy to a google cloud project, for that i had to enable 5 different APIs in google cloud UI, then create a subscription for Gemini Enterprise (whatever that is), then link it to a project, then assign it to a user. and after all that, agy couldn't find the subscription.

the best part: i couldn't cancel the subscription. so i just paid $35 for one month and left it.

that's what we started with, exactly because of the human review part. however we soon found out that there will be a lot of merge conflicts in the text (usually markdown) which heavily depends on the instructions and structure of the data. that's why for Markbase we opted for etag based validations to avoid any potential of conflicts.

For those looking for similar tools, there is also https://markbase.cloud/ as a hosted service. (Disclaimer: we built it for internal use first and would like to open source with the community help as we don’t have much experience in OSS maintenance)

We use sendops.dev for that and the rest of reputation management on AWS.

That’s obvious. But a genuine question: why does it matter? This seems to be a detailed reference document for a very technical purpose (and SEO juice for the company I guess).

Sieve is for filtering (mostly dispatch and spam blocks) but admittedly it can be used for contact segmentation as well (similar to SendQL). However it doesn't have any workflow (drips for example) idioms.

These DSLs are not there to replace templates. They are to define email lifecycle: those are different things. Email lifecycle dictates "who" gets an email (ie anyone with a Pro plan) and "when" they get an email (after they upgrade to the Pro plan). Template defines "what" they get (the email content etc). Those are different things.

You can do the "what" part (template) via WYSIWYG or django template or ReactEmail,... Sendlang is the equivalent of your django code but for the lifecycle part.

I agree that a lot of marketeers send spam but that doesn't mean email as a category is just bad and should be blocked. I am all for anything that can make better use of email as yet another tool in our pockets be it marketing or just run off the mill transactional emails we all send from SaaS (password resets and whatnots).

I don't think this is about that. A lot drip campaign and segmentation tools are based on WYSIWYG editors or UI based flow editors, which puts them out of reach of agents. This turns those into agent friendly workflows. The app will send the email however it sends it before: via SES or whatever via your own code.

Meta: Can someone more familiar with the rules of HN please tell me why some Show HN posts get immediately “flagged” while others don’t? I have seen commercial entires like this be flagged while this one is on the first page.

Genuine question: why was this post flagged. what rule does it violate?

Cannot agree more. As part of our SOC2 we have to log and respond to all inbound vulnerability reports. Before it was easy to tell if a report was just a bounty hunter looking for a low hanging fruit. Now well crafted emails with seemingly legitimate disclosures take a lot of time to validate and triage.

Our solution was to build a tool that uses LLMs to assess the report before it gets to us. Honestly I wish we didn’t have to do this but it works and has really allowed us to spend our time on the actual good reports. (Feel free to check it out at fortworx.com if you want)

For our metrics and autoscaling engine at Cloud 66, we went through 5 iterations before settling on Clickhouse: 1. Redis 2. Cassandra 3. Handrolled: Ruby + RabbitMQ 4. Handrolled: Go + RabbitMQ 5. Clickhouse

Every time we reached some limit or huge optimization burdens that were unfeasible. Clickhouse has been rock solid for the past 4 years.

In a previous life I used to model insurance payouts for residential mortgages. The average we used was within 7 years.