was setting things around how agents should handle memory in the workspace we're buildin'
obv. didn't really want agents blindly saving everything from every conversation
so went with a proposal system. they can suggest things worth remembering, but nothing gets saved into future context until the user accepts it
also kept memories scoped to the user and the agent that created them
otherwise you just end up with agents remembering all sorts of random stuff lol
now for tools that send stuff out via agents (gmail send, github issues, http posts), normal retries don't work normally
- coz a request timing out doesn't necessarily mean it failed
it might've actually gone through. so retrying there suddenly means someone's getting the same email twice lol
so it's better to reserve each tool call in db before dispatching it. if the call succeeds, juss mark it as succeeded. if the worker dies or the response gets lost in between, it becomes uncertain and isn't retried automatically
the user can then check the provider and reconcile it from the execution page
was originally planning to use tavily for web search here, but later dropped it
- usin' gpt-6-luna through openai's responses api, which already supports function calling + web search
it's prob. the cheapest one i found that supports both. gpt-5-nano is even cheaper, but goes away this dec
so didn't really see the point of adding another provider, api key and integration
like knowin' what NOT to add is just as important as knowing what to lol
especially when AI's throwin 10 different services and fancy architectures at you for every small problem haha
was originally planning to use tavily for web search here, but later dropped it
- usin' gpt-6-luna through openai's responses api, which already supports function calling + web search
it's prob. the cheapest one i found that supports both. gpt-5-nano is even cheaper, but goes away this dec
so didn't really see the point of adding another provider, api key and integration
like knowin' what NOT to add is just as important as knowing what to lol
especially when AI's throwin 10 different services and fancy architectures at you for every small problem haha
was testing worker recovery and noticed the same old problem with workers
- an old worker could wake up even after another worker had already picked up the same run. and it could still try writing to the db
normally bullmq handles the job lock, but still u need something at the db level too for these cases
so added postgres leases with fencing tokens. every new worker gets a higher token, and every write checks it
means if an old worker tries writing with an outdated token, it just gets rejected
ig we gettin' better with intuitions xD
so in a recent interview of mine, got asked what i've done in AI
i started explaining things i've built across my work and full-stack projects - AI workflows, a time-tracking system using Windows APIs to capture activity and feed it to an LLM with memory and previous context, structured outputs and other integrations, etc...
but then came the follow-up:
what have u actually done in AI beyond integrating models into applications and building workflows around them?
he was more interested in things like agents and the engineering behind them
and in my head i was like, wait... this was an SDE role, not an AI/GenAI engineering role xD
but honestly, that stuck with me
maybe it's rare to get asked this in an SDE interview, especially as a fresher, but with how quickly the market is changing, you never know what's expected in that 1 opportunity you really want
so thought it's better to explore these areas now and be prepared than leave it for later
that's pretty much what led me to orvia.
it's a workspace for creating and supervising general-purpose AI agents, with configurable tools, persistent memory, execution limits and human approval for sensitive actions
- the agent loop uses Vercel AI SDK + OpenAI, with execution handled by separate Node workers through BullMQ/Redis. postgres is the main truth, with pgvector for memory retrieval
- focused a bit on durable execution too - checkpoints, worker recovery, idempotency for external actions, approval-based pause/resume, execution tracing, etc
juss wanted to understand more of the infra and engineering behind agents themselves
so yaa :)
my 10-month run with the UK-based stealth startup came to an end yesterday.
been quite a journey!
> looking back at how much i've grown, both technically and beyond, i'm genuinely grateful for the opportunity, the people, and everything i've learned along the way
couldn't have asked for a better one 🖤
btw, it all started with a post on X and ended here as well (on a good note)
- truly the Everything platform lol
atp i'm convinced having the worst timing when it comes to buying domains lol
- first it was https://t.co/3cM1OsES06
- then https://t.co/AI6aa0iKAG
- and finally https://t.co/3plzHxQqx8...
legit all gone by the time i finally decided to buy them
bro let me have a domain 😭
was working on something recently and had to decide whether to make parts of it proper agents or keep them as workflows
tbh the boundary b/w the two feels ridiculously thin these days
but eventually, ended up leaning pretty hard towards workflows (in my case)
not because the system isn't agentic.
the models still reason, make decisions, research, evaluate, etc...
but personally, i never want the model deciding what the system does next unless there's a real reason for it
if i can define that same path in code, i'll do it anyday!
coz every time you hand orchestration to another agent, you're also adding:
- another context boundary
- another failure mode
- another thing to observe
- another thing to debug
and a heck lot of unnecessary overhead...
ik multi-agent systems are indeed powerful.
but i think they're often used to solve a problem that good orchestration could've solved much more simply
juss give models autonomy where the problem actually demands it
not just coz you can.
@striver_79 as someone who've been around ur content for 2-3 years, this seems super impressive dude
leave the voice and text for a moment, the texture, speed and depth in voice at needed timestamps is close to perfect
crazy pull man @dineshkum4r
haha, a year to this.
pretty basic looking back, but was also my 1st time working with a bunch of things i'd never really dealt with before like:
- background functions
- payments (through Polar though)
- tightly coupled external services (Stream with OpenAI)
- post-processing across different layers
- even shadcn lol
now for the last couple of weeks, been thinkin' about revamping this into an actual usable product
went through the diff possibilities, dropped a few and finally got to one where there's still quite a scope lol
so, here comes version 1.5:
> preparations built around an actual situation - role, company, documents, research and context
> research pipeline pulls company + internet evidence, processes it and builds a situation brief
> 30/45/60 min realtime voice sessions, dynamically steered - probing, following up on weak answers, digging deeper when needed
> full session processed through multiple stages into an evidence-backed report with weaknesses, missed signals and areas to work on
also went pretty deep into the economics before settling on this
- worked out the average cost across the different session lengths + all the processing around em, and i feel monthly subscriptions just don't make much sense for this model rn
- so 1.5 is gonna be one-time sessions for now, with pretty much no margin initially. wanna get the product out there first and figure the rest out later
and yaa core flow is working end-to-end now
just tightening the UX, costs and doing a pretty major UI revamp
(btw there's v2.0... that's gonna be the main one)
got some pretty crazy ideas for where this can go and how close we can get to simulating the damn entire thing
but lets leave that for then haha
1.5 soon!
Introducing Wiora...!
- an AI-powered video meeting platform where custom agents join live calls, generate transcripts, summaries, and enable post-call insights.
https://t.co/RaZClavCuf
@aksenHQ at that point of time, ig it was controlling api cost for the free users while still giving them free demo
ultimately used a bg function that auto cuts meeting for free users after 45s