Feature/eng 107 strike agent robopages nerve testing templates

[evilsocket]

Working on nerve_basic template

[linear]

ENG-107 Strike Agent - Robopages / Nerve testing + templates

Would love to see some alternative agents that work in the strike system, help us understand the limits of mechanics and what not.

[monoxgas]

One thought here that I didn't think about on our call, we actually have both guidance at a strike level, as well as guidance at a zone level (which would be tricky to apply here as the agent is expected to operate equivalently in all zones.

The agent will probably work fine, but be missing some useful information like "In this zone, you should be targeting X server"

Might be worth exploring dynamic guidance gathering on container start as an extension/alternative here.

[evilsocket]

yeah i realized that after pushing XD ... i'll start simple and add the zones guidance as part of the prompt but yes, it seems like a dropship endpoint to fetch strikes specific guidance would be ideal.

[evilsocket]

@monoxgas added the zones guidance to the nerve_basic and rigging_loop templates - i'm really not happy with this approach and 100% agree that the cleanest solution would be for the strike.yml file itself to define what to expose to the agent and then a http://dropship/context endpoint to return an AgentContext model at runtime.

[evilsocket]

instead of the booleans we talked about during the call, what if the strike.yml contains a piece of jinja2 template code defining what to return (of its own fields) to the agent? Something like:

...
...

dropship:
    ....

zones:
  ...

agent_context: |
    {{ self.guidance }}
    {% if self.zones is defined and self.zones|length > 0 %}
    You can interact with the following zones:
    {% for zone in self.zones %}
        {{ zone.name }}: {{ zone.guidance }}
    {% endfor %}
    {% endif %}

So that the http://dropship/context handler reads this as part of the Strike model, sets self to the model itself and returns the output to the agent. I think this approach is cleaner and more versatile than the booleans we discussed and could be leveraged for all sorts of different cases.

[monoxgas]

Seems like we are getting closer to the current design of having the dropship prepare endpoints/env vars for the agent so it has the context it needs. I like the idea of expanding this in general. I'll have to give the jinja template some thought, I'd like to avoid it if we can to reduce complexity, but it adds flexibility if we need it.

Here is where we can pass all any strike information to the agent via an ENV var: https://github.com/dreadnode/crucible/blob/2509eaee1311408e5701f65cd9bbac07493def6b/components/dropship/app/manager/base.py#L240 (guidance is a concatenation of strike + zone guidance, but they aren't delineated)

I also originally mounted a route on the dropship so the agent could get the guidance, but took it out: https://github.com/dreadnode/crucible/blob/2509eaee1311408e5701f65cd9bbac07493def6b/components/dropship/app/manager/base.py#L352

Would be easy to add back in a context endpoint that returned some structured JSON - sounds like a good place to put guidance, network layout/services/endpoints/hosts, and output structure/formatting/rules.

That seems like a better place to do any final adaptations to the agent before it kicks off. Nerve/rigging comes up, hits that endpoint, parses from known structure and adjusts internal logic + templates as needed.

[evilsocket]

@monoxgas i have to merge this as it is in order to work on https://linear.app/dreadnode/issue/ENG-99/cli-agent-templates-per-strike ... i hope that's ok!